پر بودن عنوان، پیششرط، مراحل و نتیجهٔ مورد انتظار به این معنا نیست که یک تستکیس قابل اجرا، قابل داوری یا متصل به ریسک است. بازبینی مؤثر نیز با چند کامنت پراکنده و زدن دکمهٔ Approve تمام نمیشود. یک Review قابل اتکا باید معلوم کند کدام Revision، با کدام Basis و معیار، از چه Perspective، چه Findingهایی گرفته، هر Finding چگونه Disposition شده، Rework در کدام Revision آمده و Closure با چه شاهدی انجام شده است.
این راهنما پروتکل کامل بازبینی Test Work Product را ارائه میکند: Review Contract، انتخاب عمق بر پایهٔ ریسک، Baseline immutable، تکنیکهای خواندن، Finding قابلبازتولید، بازخورد دقیق، Disposition، Rework، Re-review، Closure و یادگیری. تمرکز فقط روی Test Case نیست؛ Test Condition، Scenario، Charter، Data specification، Oracle، Automation script، Plan section و Evidence profile هم میتوانند Work Product بازبینیشونده باشند.
پاسخ کوتاه: Review مؤثر چه زنجیرهای دارد؟
Purpose + decision -> versioned work-product baseline -> basis/source snapshot -> risk-tailored criteria and perspectives -> independent preparation -> normalized findings -> triage and disposition -> rework in a new revision -> evidence-based re-review and closure -> metrics, learning and criteria update
خروجی Review «فهرست نظرها» نیست؛ مجموعهای از Findingهای دارای Locator، Criterion، Observation، Consequence و State است که به Revision مشخص وصلاند. Approval نیز باید دامنه، Authority و شروط خود را داشته باشد و هرگز بهتنهایی اثربخشی تست یا کیفیت محصول را تضمین نمیکند.
مرز مالکیت این مقاله با مطالب نزدیک
| موضوع | مالک آن چه میپرسد؟ | مرز با Review Protocol |
|---|---|---|
| نوشتن Test Case | چگونه Case را طراحی و مستند کنیم؟ | Review کیفیت Revision موجود را در برابر معیارها بررسی میکند. |
| تحلیل Test Basis | از Requirement چه سؤال و Conditionی استخراج شود؟ | Basis ورودی Review است؛ اصلاح Basis باید در Artifact خودش ثبت شود. |
| انتخاب Artifact/detail | Scenario، Case، Charter یا Model کجا مناسب است؟ | Review نباید همه را به قالب Test Case مجبور کند. |
| تسهیل جلسه | جلسه چگونه زمانبندی و اداره شود؟ | این مقاله Lineage و lifecycle Finding را مالک است. |
| Defect management | نقص محصول چگونه Triage و رفع شود؟ | Review Finding دربارهٔ Work Product است؛ ممکن است Product Defect نباشد. |
| Documentation freshness | سند چه وقت stale یا drifted میشود؟ | Review Baseline و Source freshness را مصرف و بررسی میکند. |
برای ساخت خودِ Case به راهنمای نوشتن تستکیس حرفهای، برای پرسش از Basis به تحلیل نیازمندی در STLC و برای انتخاب Scenario/Case/Charter به راهنمای انتخاب Artifact تست مراجعه کنید.
Review، Static Analysis، Dynamic Test و Audit یکی نیستند
| فعالیت | موضوع | مکانیک غالب | خروجی محدود |
|---|---|---|---|
| Manual review | Work Product قابلخواندن | خواندن/مدلسازی/پرسش انسانی | Finding و ارزیابی معیار |
| Static analysis | Artifact دارای ساختار قابل ابزار | Rule/parser/analyzer | Diagnostic؛ نیازمند تفسیر |
| Dynamic testing | Test object قابل اجرا | تحریک و مشاهدهٔ رفتار | Outcome/Evidence |
| Audit | فرایند/رکورد در برابر مرجع | بررسی مستقل و دامنهدار | Audit finding/conclusion |
| Approval | نسخه و دامنهٔ نامدار | اعمال حق تصمیم | Decision record |
ISTQB CTFL v4.۰.۱ بازبینی دستی و تحلیل ایستا را زیر چتر Static Testing توضیح میدهد و میگوید Work Productهای خواندنی متنوعی قابل Review هستند. این به آن معنا نیست که یک Checklist انسانی جای اجرای Test object یا Audit رسمی را میگیرد. منبع آموزشی: ISTQB CTFL v4.0.1.
چه Test Work Productهایی قابل بازبینیاند؟
| Work Product | پرسش Review نمونه | ریسک تعمیم قالب |
|---|---|---|
| Test Condition | به Risk/Basis قابل ردیابی و قابل آزمون است؟ | اجبار Step-level detail |
| Test Scenario | Flow/actor/outcome و مرز آن روشن است؟ | فرض کاملبودن Coverage |
| Low-level Test Case | Data/Oracle/Precondition/cleanup قابل اجراست؟ | مراحل بیشازحد شکننده |
| Exploratory Charter | Mission، scope، risks و timebox روشناند؟ | تبدیل Charter به Script |
| Test Data spec | هویت، provenance، constraints و privacy مشخص است؟ | کپی دادهٔ واقعی |
| Oracle spec | منبع Expected و tolerance مستقل است؟ | تکرار پیادهسازی |
| Automation script | Claim، assertion، determinism و diagnostics مناسباند؟ | Code style-only review |
| Evidence profile | چه شاهدی برای کدام تصمیم کافی/نامعتبر است؟ | Screenshot بهعنوان اثبات جهانی |
معیارها باید با نوع Artifact سازگار باشند. Charter فاقد Step-by-step لزوماً ناقص نیست و Test Case کمجزئیات لزوماً ضعیف نیست؛ سطح جزئیات تابع هدف، مصرفکننده، Risk، تکرارپذیری لازم و هزینهٔ نگهداری است. برای Charter و Session، راهنمای تست اکتشافی ساختاریافته مرجع خوشه است.
Review Goal را پیش از معیار بنویسید
ReviewGoal {
review_id, purpose, decision_supported,
work_product_type, subject_scope,
risk_context, target_revision,
depth, techniques, perspectives,
criteria_set, finding_policy,
disposition_authority, exit_policy
}
هدف «بهبود کیفیت» برای انتخاب Review کافی نیست. آیا میخواهید قابلیت اجرا را بسنجید، Coverage mapping را وارسی کنید، Oracle ambiguity را کم کنید، تغییر Revision را بررسی کنید یا یک Gate مشخص را تغذیه کنید؟ هر هدف به معیار، Perspective و Sampling متفاوت نیاز دارد.
Review Contract قابلکپی
ReviewContract {
review_id, revision, owner,
purpose, audience, decision,
work_product_ids[], baseline_revision,
basis_snapshot_ids[], registry_snapshot_ids[],
criteria_version, checklist_version,
included_sections, excluded_sections,
risk_tiers, sampling_rule,
required_perspectives[], reviewers[],
entry_checks[], finding_schema,
severity_policy, disposition_states,
rework_policy, re_review_policy,
exit_claim, authority, due_at,
evidence_store, retention, access_class
}
ISO/IEC ۲۰۲۴۶:۲۰۱۷ در صفحهٔ عمومی خود یک چارچوب عمومی برای Review انواع Work Product، شامل فرایند، فعالیت، وظیفه، تکنیک و قالب مستندسازی معرفی میکند. چون متن کامل استاندارد در صفحهٔ عمومی نیست، این مقاله Contract بالا را بهعنوان پیادهسازی آموزشی خود ارائه میکند، نه نقل بند یا اثبات انطباق. منبع: ISO/IEC 20246:2017.
Baseline را منجمد کنید، نه اینکه همکاری را متوقف کنید
| هویت | نمونه | چرا لازم است؟ |
|---|---|---|
| Work Product ID | TC-PAY-07 | نام فایل و عنوان تغییر میکند |
| Baseline revision | r2 / digest abc… | همه یک نسخه را بخوانند |
| Basis snapshot | REQ-PAY-v6 | معنا و Scope زمان Review معلوم باشد |
| Registry snapshot | RISK-REG-12 | Coverage refها قابل اعتبارسنجی باشند |
| Criteria version | REV-CRIT-v2 | Gate پس از Review عوض نشود |
| Tool/export version | manifest-2026-04-15 | View با منبع اشتباه نشود |
Author میتواند حین Review نسخهٔ جدید بسازد، اما Findingهای دور جاری باید به Baseline اولیه متصل بمانند. سپس یک Diff مشخص r2→r3 موضوع Re-review میشود. ویرایش بیصدای همان Revision، Finding را از Locator جدا و Closure را غیرقابل بازسازی میکند.
Entry check: آیا Work Product آمادهٔ Review است؟
- هدف و مصرفکنندهٔ Artifact معلوم است؛
- ID، Revision و مالک مشخصاند؛
- Basis و Registry snapshot قابل دسترسیاند؛
- محدوده و Out-of-scope Review نوشته شده؛
- قالب/Schema حداقل برای نوع Artifact معتبر است؛
- Review criteria و Perspective پیشاپیش منتشر شدهاند؛
- تغییرات نسبت به Revision قبلی قابل مشاهدهاند؛
- راز، PII و دادهٔ غیرمجاز حذف یا دسترسی محدود شده است؛
- Reviewer زمان و Context لازم دارد؛
- مسیر Finding، Disposition و Rework آماده است.
Entry check Gate کیفیت نیست؛ فقط از هدررفتن Review روی Artifact ناشناس یا غیرقابل دسترسی جلوگیری میکند. در Review سبک ممکن است برخی فیلدها حذف شوند، اما این Tailoring باید آگاهانه و ثبتشده باشد.
عمق Review را بر پایهٔ ریسک Tailor کنید
| سطح نمونه | موقعیت | عمق/شاهد | بازبین |
|---|---|---|---|
| Quick check | تغییر کماثر و محلی | Schema + Diff + یک Perspective | Peer مناسب |
| Focused review | Risk یا Oracle نامدار | معیار تخصصی + Scenario dry-run | Test + Domain capability |
| Multi-perspective | Cross-system یا user-impacting | Basis/trace/data/oracle/ops | Perspectiveهای مکمل |
| Formal/controlled | تعهد سازمانی/قراردادی یا اثر بالا | Baseline، records، independence و closure سختتر | طبق Governance |
| Re-review only | Rework محدود | Diff + regression of affected relations | Reviewer/authority تعیینشده |
«همهٔ تستکیسها باید جلسهٔ رسمی داشته باشند» و «Peer review برای همه کافی است» هر دو تعمیم نادرستاند. Depth، نمونه، Independence و Record burden را با پیامد خطا، تغییر، نوآوری، سابقه، قابلیت بازیابی و هزینه تنظیم کنید.
چگونه Scope و Sampling را تعریف کنیم؟
ReviewSample {
population_snapshot, sampling_unit,
inclusion_rule, exclusion_rule,
method: full | risk | stratified | random | change-based,
seed_if_random, strata[],
selected_ids[], nonresponse_or_unreadable[],
limits_on_inference
}
Sample موفق به معنی سالمبودن جمعیت نیست. اگر ۲۰ Case از ۲۰۰ Case را Risk-based خواندهاید، Claim را به همان نمونه و Rule محدود کنید. برای Artifactهای بحرانی یا روابط مرزی شاید Full review لازم باشد؛ برای مجموعهٔ بزرگ میتوان Schema را تمامجمعیت و Semantic review را نمونهای انجام داد.
معیارهای Review را لایهلایه کنید
| لایه | پرسش | نمونه Finding |
|---|---|---|
| Identity | Artifact/Basis/Revision دقیق است؟ | Basis قدیمی |
| Schema | فیلد/نوع/ساختار لازم وجود دارد؟ | Oracle ref خالی |
| Semantic | عبارت معنای قابل داوری دارد؟ | «باید درست کار کند» |
| Traceability | Reference معتبر، یکتا و جهتدار است؟ | Coverage ID ناشناخته |
| Executability | Actor/Data/Environment/Precondition فراهم است؟ | «کاربر معتبر» مبهم |
| Oracle | Expected مستقل، دقیق و دارای tolerance است؟ | Expected نتیجه را تکرار میکند |
| Risk/evidence | تعهد شاهد Risk نامدار را پشتیبانی میکند؟ | فقط Happy path |
| Maintainability | کوپلینگ و جزئیات شکننده کنترل شده؟ | Selector نمایشی بیدلیل |
| Accessibility | Artifact برای مصرفکننده قابل دریافت/خواندن است؟ | معنا فقط با رنگ |
| Security/privacy | داده و Link حداقل/مجاز است؟ | Token واقعی در Step |
| Freshness | Source/Review-by و trigger معتبر است؟ | Oracle منقضی |
پر بودن فیلد فقط Schema را میسنجد؛ نمیگوید مقدار درست، کافی یا تازه است. برای چرخهٔ Freshness و Drift به راهنمای مستندات تست زنده رجوع کنید.
چکلیست ابزار یادآوری است، نه سقف فکر
- Checklist ID و نسخه را ثبت کنید؛
- آن را با Artifact type، Risk و Goal Tailor کنید؛
- هر سؤال را به Criterion ID یا rationale وصل کنید؛
- گزینههای Yes/No/NA/Unknown را معنا کنید؛
- NA نیازمند دلیل/Authority باشد؛
- پاسخ Yes بدون Evidence ref در موارد اثرگذار کافی نباشد؛
- یافتههای خارج از Checklist پذیرفته شوند؛
- مواردی که Reviewهای قبل از دست دادهاند به Candidate update تبدیل شوند؛
- تغییر Checklist برای Findingهای باز جاری، Gate را پسنگر عوض نکند.
سرفصل رسمی ISTQB CTAL-TA v4.۰ نیز Checklist را جامع و محدودکننده نمیداند و بر Tailoring و بهروزرسانی آن با الگوهای ازدسترفته تأکید دارد. این منبع آموزشی تکنیک را توضیح میدهد؛ انتخاب سازمانی یا اثربخشی Review را تضمین نمیکند. منبع: ISTQB CTAL-TA v4.0.
Scenario-based review: Artifact را dry-run کنید
| سناریوی خواندن | Reviewer چه میکند؟ | چه چیزی ممکن است آشکار شود؟ |
|---|---|---|
| Executor handoff | بدون سؤال بیرونی Case را اجراپذیر میسازد | Precondition/Data/Step ambiguity |
| Failure diagnosis | از Failure به Evidence و Oracle برمیگردد | Diagnostics ناکافی |
| Requirement change | اثر تغییر Basis را دنبال میکند | Trace ناقص/کوپلینگ |
| Environment unavailable | Fallback و limitation را بررسی میکند | Dependency پنهان |
| Result reuse | Build/Data/Freshness را تطبیق میدهد | Reuse claim نامعتبر |
| Cleanup/retry | تکرار Case را شبیهسازی میکند | State leak/non-idempotence |
Dry-run اجرای واقعی سیستم نیست؛ اجرای ذهنی/مدلی مسیر استفاده از Work Product است. از آن نباید PASS رفتار محصول نتیجه گرفت. Scenario فقط View خاص میدهد و باید با معیارهای دیگر ترکیب شود.
Role-based و Perspective-based reading
| Perspective | Artifact مشتقشده/پرسش | Blind spot محتمل |
|---|---|---|
| Test executor | آیا میتوان Attempt معتبر ساخت؟ | اثر کسبوکار |
| Domain/Oracle | Expected بر چه Rule مستقلی استوار است؟ | محدودیت ابزار |
| Risk owner | کدام uncertainty با چه Evidence کاهش مییابد؟ | جزئیات اجرا |
| Automation maintainer | چه قرارداد/locator/data پایدار است؟ | معنای کاربر |
| Operations | Signal/cleanup/recovery و محیط واقعی چیست؟ | طراحی Coverage |
| Accessibility user | آیا interaction و expected behavior قابل استفاده است؟ | زیرساخت |
| Privacy/security | داده، دسترسی و retention مجاز است؟ | کفایت Functionality |
Perspective یک لنز کاری است، نه عنوان شغلی ثابت. یک فرد ممکن است چند قابلیت داشته باشد، اما ثبت Perspective کمک میکند خلأها و تکرارها دیده شوند. تنوع افراد بهخودیخود Coverage کامل Review را اثبات نمیکند.
Diff-based review: تغییر کوچک را در Context بخوانید
- Diff متن را با Diff معنایی یکی ندانید؛ تغییر Source ممکن است بدون تغییر متن، Artifact را stale کند.
- روابط ورودی و خروجی بخش تغییرکرده را بررسی کنید؛ Coverage، Data، Oracle و Cleanup ممکن است متاثر شوند.
- جابجایی/فرمت را از تغییر معنایی جدا کنید تا نویز کم شود.
- Generated artifact را از Source canonical بازتولید و Diff هر دو را بررسی کنید.
- برای تغییر پرریسک، Full-context یا Perspective اضافه لازم است.
- Re-review را فقط به خط تغییرکرده محدود نکنید اگر Invariant سراسری متاثر است.
Finding چیست و چه چیزی Finding نیست؟
| نوع رکورد | تعریف | نیازمند Disposition؟ |
|---|---|---|
| Finding | ناهمخوانی/ابهام مشاهدهشده با Criterion یا هدف | بله |
| Question | درخواست اطلاعات برای فهم/قضاوت | پاسخ/تبدیل/Closure |
| Suggestion | گزینهٔ بهبود بدون الزام Criterion | طبق Policy |
| Editorial note | اصلاح صوری کماثر | میتواند batch شود |
| Product defect | ادعای نقص در Test object | چرخهٔ Defect مستقل |
| Basis issue | ابهام/نقص در Source | رکورد در مالک Basis |
| Decision request | گزینهای نیازمند Authority | Decision record |
یک Comment thread میتواند ظرف چند نوع رکورد باشد؛ نوع آن را صریح کنید. Finding دربارهٔ Test Case را مستقیم به Defect محصول تبدیل نکنید. برای چرخهٔ Product defect و Triage به راهنمای مدیریت نقص نرمافزار مراجعه کنید.
قالب Finding قابلبازتولید
ReviewFinding {
finding_id, review_id,
work_product_id, baseline_revision,
locator, perspective, criterion_id,
observation, expected_or_rule,
consequence_or_risk,
evidence_refs[], confidence,
type, proposed_option_optional,
severity, state,
author_response, disposition,
disposition_by, rationale,
target_revision, resolution_evidence,
re_reviewed_by, closed_at
}
«این Case خوب نیست» Finding نیست. نمونهٔ قابل اقدام: «TC-PAY-۰۷ r2 / expectedResult / C-ORACLE-۱: عبارت “تراکنش موفق باشد” Outcome قابلاندازهگیری، state نهایی و Ledger invariant را مشخص نمیکند؛ Executor نمیتواند PASS/FAIL را مستقل تعیین کند. پیشنهاد اختیاری: پیوند به ORACLE-LEDGER-v2 و amount/state دقیق.»
Locator باید پس از تغییر هم قابل بازیابی باشد
| Locator | مزیت | ضعف |
|---|---|---|
| Field/Step ID | پایدارتر از شماره خط | نیازمند ID design |
| JSON Pointer/XPath | ماشینخوان | به Schema حساس |
| Line/column | ساده در Revision ثابت | با Formatting جابهجا میشود |
| Quoted anchor + hash | در متن قابل تشخیص | Quote ممکن است تکراری باشد |
| Model node/edge ID | رابطه را دقیق نشان میدهد | Export ممکن است ID را از دست بدهد |
| Diff hunk | برای Re-review مناسب | Context محدود |
Locator بدون Baseline revision کامل نیست. اگر ابزار پس از ویرایش Thread را به متن جدید منتقل کند، Manifest باید Anchor قبلی و Mapping به Revision تازه را حفظ کند.
Observation، Consequence و Proposal را جدا کنید
| جزء | سؤال | نمونه |
|---|---|---|
| Observation | در Artifact چه میبینیم؟ | currency «تومان/ریال» است |
| Criterion | با کدام قرارداد سنجیده میشود؟ | C-MONEY-2: canonical=IRR |
| Consequence | چه ابهام/ریسکی ایجاد میکند؟ | amount ممکن است ۱۰ برابر تفسیر شود |
| Evidence | چه Source/نمونهای Claim را پشتیبانی میکند؟ | Data contract v4 |
| Proposal | یک گزینهٔ ممکن چیست؟ | IRR canonical + labeled toman view |
Reviewer مجبور نیست همیشه راهحل طراحی کند؛ گاهی Author یا Domain owner Context بهتری دارد. نبود Proposal نباید Finding معتبر را حذف کند. برعکس، Proposal بدون Observation/Criterion ممکن است صرفاً ترجیح شخصی باشد.
Severity، Priority و Confidence را یکی نکنید
| بعد | پرسش | Authority نمونه |
|---|---|---|
| Severity | اگر Finding باقی بماند، پیامد آن چقدر است؟ | Policy/triage role |
| Priority | با توجه به زمان/وابستگی چه وقت رسیدگی شود؟ | Work owner |
| Confidence | Reviewer چقدر به Observation/تفسیر مطمئن است؟ | Reviewer + evidence |
| Effort | Rework و Re-review چقدر هزینه دارد؟ | Author/maintainer |
| Gate effect | کدام Exit predicate را متوقف میکند؟ | Review authority |
Finding با Confidence پایین میتواند Severity بالقوهٔ بالا داشته باشد و نیازمند Investigation باشد. Label «Critical» بدون Rule و دلیل، گفتوگو را شخصی و Metric را بازیپذیر میکند.
بازخورد دقیق، محترمانه و غیرشخصی چگونه است؟
- به Artifact/Revision/Locator اشاره کنید، نه ویژگی شخص؛
- Observation را پیش از قضاوت بنویسید؛
- Criterion یا Decision need را نام ببرید؛
- اثر را محدود و شرطی بیان کنید؛
- سؤال را به شکل سؤال ثبت کنید، نه اتهام؛
- Proposal را گزینه بدانید مگر Rule آن را الزام کرده باشد؛
- از «واضح است»، «همیشه»، «هیچکس» و نیتخوانی پرهیز کنید؛
- برای تفاوت نظر، Disposition/rationale بخواهید؛
- تحسین ساختگی یا الگوی اجباری compliment–criticism–compliment لازم نیست؛
- بحث حساس را همدلانه Sync کنید، اما نتیجه را در Record بنویسید.
نمونهٔ قبل و بعدِ یک بازخورد
| نسخه | متن | مشکل/مزیت |
|---|---|---|
| مبهم | این تست ناقص است؛ کاملش کن. | Locator، معیار و اثر ندارد |
| شخصی | شما دوباره داده را فراموش کردهاید. | روی فرد و سابقه قضاوت میکند |
| نسخهمحور | TC-PAY-۰۷ r2 / testData: Data ref خالی است؛ طبق C-DATA-۱، Executor باید Snapshot قابلبازیابی داشته باشد. | Observation و Criterion روشن |
| قابلاقدام | اثر: مبلغ/حالت اولیه قابل تکرار نیست. گزینه: DATA-SYN-PAY-v2؛ اگر NA است، rationale/authority ثبت شود. | Consequence و Option بدون تحمیل |
بازبینی مستقل پیش از جلسه
هر Reviewer باید در صورت امکان پیش از همگرایی گروهی، Artifact را با Assignment و Perspective روشن بخواند. این کار Anchoring و سلطهٔ صدای اول را کم میکند و تعداد Perspectiveهای واقعی را قابل مشاهده میسازد. اما Independence مطلق همیشه لازم یا ممکن نیست؛ Context، Risk و Governance تعیین میکند.
ReviewerAssignment {
reviewer_id, capability, perspective,
assigned_scope, criteria_subset,
baseline_revision, started_at, submitted_at,
conflicts_of_interest[], assistance_used[],
findings[], questions[], coverage_statement
}
جلسه فقط برای همگرایی لازم است، نه بلندخوانی
- Findingهای تکراری را پیش از جلسه خوشهبندی کنید؛
- Questionهای پاسخپذیر را async حل کنید؛
- زمان جلسه را صرف تضاد Criterion، اثر، Disposition و تصمیم کنید؛
- Moderator محتوا را Approve نکند مگر Authority جدا داشته باشد؛
- Notetaker State و rationale را ثبت کند، نه متن آزاد نامنسجم؛
- بحث بدون اطلاعات کافی به INVESTIGATE/DEFERRED با Owner/Due تبدیل شود؛
- سکوت جلسه Acceptance نیست؛
- صورتجلسه جای Finding registry و Decision record را نگیرد.
جزئیات Timebox، Facilitation، مشارکت و مدیریت تعارض در راهنمای تسهیل جلسه بازبینی تست قرار دارد؛ این مقاله صرفاً ورودی/خروجی و State transitionهای جلسه را مشخص میکند.
Deduplication بدون از دستدادن Perspective
DuplicateKey candidate = work_product_id + baseline_revision + locator + criterion_id MergedFinding retains: original_finding_ids[] reviewer_ids[] perspectives[] evidence_refs[] disagreements[] canonical_finding_id
دو Finding در یک Locator الزاماً Duplicate نیستند؛ ممکن است یکی Oracle ambiguity و دیگری privacy exposure باشد. Merge باید Provenance را نگه دارد. تعداد Finding کم پس از Deduplication نیز نباید بهعنوان «Review ضعیف» تفسیر شود.
Disposition: هر Finding به یک تصمیم نیاز دارد
| State | معنا | حداقل Record |
|---|---|---|
| OPEN | هنوز تصمیم نگرفتهایم | Owner/Due |
| ACCEPTED | Finding معتبر و Rework لازم است | Target revision/action |
| REJECTED | تغییر لازم نیست | Rationale + authority |
| DEFERRED | در Scope/زمان دیگری رسیدگی میشود | Target/expiry/risk |
| DUPLICATE | با Finding canonical یکی است | Canonical ID |
| NEEDS_INFO | اطلاعات برای تصمیم کافی نیست | Question/owner/due |
| RESOLVED | Rework ادعا شده و Evidence دارد | Revision/diff/evidence |
| CLOSED | Re-review/Rule Closure را تأیید کرده | Closer/time/baseline |
| REOPENED | Resolution شرط را برآورده نکرده یا regress کرده | New observation |
`DONE` بیش از حد مبهم است: آیا Finding رد شد، اصلاح شد، فقط پاسخ گرفت یا Closure تأیید شد؟ State vocabulary را نسخهدار کنید و Transitionهای مجاز و Authority هر Transition را تعریف کنید.
Author Response دفاع شخصی نیست
| پاسخ | نمونهٔ سالم | آنچه کافی نیست |
|---|---|---|
| Accept | پذیرفته؛ r3 با Diff D7 | «اوکی» |
| Clarify | Basis B6 این اصطلاح را تعریف کرده؛ لینک/بند | «همه میدانند» |
| Challenge | Criterion C4 برای Charter قابل اعمال نیست؛ Tailoring T2 | «سلیقهای است» |
| Alternative | بهجای Split، Data table parameterized؛ trade-off | تغییر بیتوضیح |
| Needs owner | Oracle متعلق به Domain role؛ Request Q9 | Forward کردن نامحدود |
Author حق دارد Finding را با شاهد به چالش بکشد. اختلاف، خطای فرهنگی نیست؛ دادهای دربارهٔ ابهام Criterion یا Context است. Authority باید rationale را ثبت کند و Reviewer نباید همواره رأی نهایی را صرفاً بهدلیل کشف Finding داشته باشد.
Rework باید Revision تازه بسازد
ReworkRecord {
rework_id, accepted_finding_ids[],
source_revision, target_revision,
changed_locators[], change_summary,
diff_uri, new_or_changed_source_refs[],
author, completed_at,
regression_relations_checked[],
unresolved_findings[]
}
اگر Finding روی r2 ثبت شد، اصلاح باید در r3 یا شناسهٔ تغییر معادل قابل ردیابی باشد. تغییر Expected result ممکن است Data، Oracle، Coverage یا Automation را نیز متاثر کند؛ Rework فقط جای کلمه را عوض نمیکند، روابط وابسته را نیز ارزیابی میکند.
Re-review و Closure چه چیزی را بررسی میکنند؟
- Target revision همان Revision ادعاشده است؛
- Diff واقعاً Observation و Criterion Finding را پاسخ میدهد؛
- Resolution evidence قابل بازیابی و مجاز است؛
- تغییر، Finding تازه یا Regression رابطهای نساخته است؛
- Basis/Registry/Criteria هنوز همان Context یا بهدرستی Supersede شدهاند؛
- Deferred/Rejected/Duplicate rationale و Authority کاملاند؛
- هیچ Finding بازِ Gate-blocking باقی نمانده یا Exception معتبر دارد؛
- Closure baseline دقیقاً Revision نهایی است؛
- Closure فقط دامنهٔ Review را Claim میکند.
`RESOLVED` ادعای Author/Workflow است؛ `CLOSED` تأیید Rule یا Re-review است. در Risk پایین میتوان این دو را با Policy یکی کرد، اما معنا باید روشن بماند.
Exit Claim را محدود بنویسید
ReviewExitClaim {
review_id, final_revision,
reviewed_population_or_sample,
criteria_version, perspectives_completed[],
finding_totals_by_state,
blocking_findings_remaining[],
exceptions[], unknowns[],
conclusion, authority, decided_at,
explicitly_not_claimed[]
}
بهجای «Test Case approved and complete» بنویسید: «TC-PAY-۰۷ r3 در Scope S1 با Criteria v2 و Perspectiveهای test-design/domain-ledger بازبینی شد؛ Finding blocking باز ندارد؛ Accessibility/Production parity خارج از Scope است.» این Claim نه Coverage کامل، نه کشف همهٔ نقصها و نه کیفیت محصول را اثبات میکند.
Approval، Recommendation و Risk Acceptance را جدا کنید
| رکورد | ادعا | مرجع |
|---|---|---|
| Review conclusion | وضعیت معیارها در Scope | Review authority |
| Recommendation | نظر حرفهای دربارهٔ اقدام بعدی | Capability role |
| Artifact approval | نسخه برای مصرف نامدار پذیرفته است | Artifact owner/authority |
| Exception | Finding/criterion با شروط و expiry موقتاً پذیرفته شده | Exception authority |
| Risk acceptance | ریسک باقیمانده پذیرفته شده | Risk owner |
| Release decision | انتشار با همهٔ ورودیها تصمیمگیری شده | Release authority |
Reviewer یا QA صرفاً با ثبت Finding صاحب اختیار انتشار نمیشود. نقشها را بر اساس قابلیت و حق تصمیم تعریف کنید؛ راهنمای رهبری تضمین کیفیت مرز مالکیت مشترک و Authority را توضیح میدهد.
آزمایش تکرارپذیر: ۱۲ فیلد پر چرا PASS نبود؟
برای آزمودن مکانیک Review، Fixture کاملاً ساختگی SYN-TEST-WORK-PRODUCT-REVIEW-01 ساخته شد. کنترل سطحی فقط ۱۲ فیلد را بررسی کرد: ID، Revision، Title، Objective، Priority، Coverage refs، Precondition، Steps، Expected result، Currency، Environment و Cleanup. همه غیرخالی بودند؛ بنابراین نتیجهٔ سطحی `PASS` و `۱۰۰%` شد.
Contract و دادهٔ Fixture ساختگی
| عنصر | Contract | Draft |
|---|---|---|
| Work Product | TC-PAY-07 r3 | r2 |
| Basis | REQ-PAY-v6 | REQ-PAY-v5 |
| Criteria | REV-CRIT-v2 | REV-CRIT-v1 |
| Coverage Registry | R1/R2/R3 | R2/R2/C99 |
| Precondition | State و fixture دقیق | «کاربر معتبر» |
| Data/Oracle | Reference لازم | هردو خالی |
| Currency | IRR canonical | «تومان/ریال» |
| Perspectives | test-design + domain-ledger | فقط test-design |
| Finding | Locator/Criterion/State معتبر | بدون Locator/Criterion و State=_DONE_ |
| Lineage | r2→r3 و Closure r3 | Rework همان r2 و Closure r1 |
خروجی واقعی اجرای Fixture
fixture: SYN-TEST-WORK-PRODUCT-REVIEW-01 superficial: PASS | filled=12/12 | percent=100 auditedDraft: HOLD findings (17): 1 wrong-baseline:r2->r3 2 stale-basis:REQ-PAY-v5->REQ-PAY-v6 3 stale-criteria:REV-CRIT-v1->REV-CRIT-v2 4 duplicate-coverage-ref:R2 5 unknown-coverage-ref:C99 6 ambiguous-precondition 7 unbound-test-data 8 tautological-expected-result 9 missing-oracle-ref 10 ambiguous-or-noncanonical-currency:تومان/ریال 11 missing-required-perspective:domain-ledger 12 finding-missing-locator:F-1 13 finding-missing-criterion:F-1 14 invalid-finding-state:F-1:DONE 15 self-disposition-not-allowed:F-1 16 silent-rework-without-new-revision 17 closure-baseline-mismatch:r1->r2 corrected: READY_FOR_CLOSURE_REVIEW | findings=0
اصلاح Fixture و مرز نتیجه
نسخهٔ اصلاحشده Work Product را به r3، Basis را به v6، Criteria را به v2 و Coverage را به R1/R2/R3 تغییر داد؛ Precondition و Data/Oracle دقیق شدند، IRR canonical شد و Perspective دامنه اضافه شد. F-۱ با Locator، Criterion، State=RESOLVED، Authority مستقل و Diff r2→r3 ثبت و Closure روی r3 انجام شد. نتیجه فقط `READY_FOR_CLOSURE_REVIEW` است، نه Approved خودکار.
- همهٔ Artifactها، Revisionها، نقشها، دادهها، قواعد و Findingها ساختگیاند.
- Fixture اثربخشی Test Case، Coverage adequacy، صحت Basis/Oracle یا کیفیت محصول را نمیسنجد.
- وجود Reference اصالت یا کفایت Source/Evidence را اثبات نمیکند.
- ۱۷ Finding برای Benchmark تیم، Reviewer یا ابزار قابل استفاده نیست.
- نتیجه هیچ گواهی ISO/ISTQB، Risk acceptance یا Release decision نیست.
سناریوی ایرانی کاملاً ساختگی: Review تست پرداخت آفلاین
یک آزمایشگاه قطعشده از شبکه برای Checkout خیالی تصور کنید: Order، PaymentAttempt، PSP Stub جعلی، Callback، Ledger آزمایشی، Reconciliation و Notification fake. Work Product مورد Review یک Test Case برای Timeout-after-fake-commit است. هیچ بانک، PSP، مشتری، پذیرنده، پول یا تراکنش واقعی در کار نیست.
| Perspective | سؤال Review | Finding نمونه |
|---|---|---|
| Test design | Precondition/Step/Outcome مستقلاند؟ | Attempt state پیش از Retry معلوم نیست |
| Ledger domain | اثر مالی ساختگی چگونه داوری میشود؟ | Expected بین تومان/ریال مبهم است |
| Reliability | Timeout قبل/بعد commit تفکیک شده؟ | Failure point هویت ندارد |
| Data | Fixture و cleanup تکرارپذیر است؟ | Seed snapshot و idempotency key خالی است |
| Observability | Evidence برای تشخیص duplicate چیست؟ | فقط UI message ثبت میشود |
| Privacy/security | دادهٔ حساس یا Secret وجود دارد؟ | نمونهٔ واقعی OTP نباید ذخیره شود |
قرارداد هویت، مبلغ و زمان در سناریوی فارسی
- Tenant، Order، Attempt، Callback event، Ledger entry، Run، Build، Case و Finding شناسههای جدا دارند.
- مبلغ canonical فقط IRR ساختگی است؛ نمایش تومان دارای label و Rule صریح است.
- اعداد فارسی «۱۲۵۰۰۰»، عربی «۱۲۵۰۰۰» و لاتین «۱۲۵۰۰۰» ورودیهای Unicode مصنوعیاند.
- Instant با ISO ۸۶۰۱/UTC، View با Asia/Tehran و تاریخ جلالی فقط Presentation ثبت میشود.
- Retry، duplicate callback، late/reordered callback و timeout پیش/پس از commit جعلی جدا هستند.
- نام، موبایل، ایمیل، IP، حساب، کارت، PAN، CVV2، OTP، Cookie، Token، Secret، Log و Screenshot واقعی ممنوعاند.
این Lab هیچ توصیهٔ بانکی، مالی، حقوقی، مالیاتی، امنیتی، حریم خصوصی یا تحریمی دربارهٔ ایران نیست. «موفقیت پرداخت» نیز در Fixture به یک State/Invariant مصنوعی محدود است و رفتار هیچ سامانهٔ واقعی را بازنمایی نمیکند.
Finding Pack نمونه برای Lab
F-LAB-07 work_product: TC-TIMEOUT-04 r2 locator: expectedResult.ledger.amount perspective: domain-ledger criterion: C-MONEY-2 / canonical currency must be explicit observation: expected value is written as "۱۲۵۰۰ تومان/ریال" consequence: executor may compare 12,500 or 125,000 IRR evidence: DATA-CONTRACT-SYN-v4#money severity: HIGH (fixture policy), confidence: HIGH state: ACCEPTED target_revision: r3 resolution: value=125000 IRR; display_toman=12500 labeled resolution_evidence: DIFF-r2-r3#expectedResult.ledger.amount closure: pending domain-ledger re-review
امنیت و حریم خصوصی در Review
| ریسک | کنترل پیش از Review | کنترل در Record |
|---|---|---|
| Secret در Step/Log | Scanner + redaction | Reference به vault، نه مقدار |
| PII در Test data | Synthetic/minimized data | Access class/retention |
| Screenshot حساس | Crop/sanitize/approval | Restricted evidence URI |
| Reviewer خارجی | Need-to-know و NDA/policy | Scoped export |
| Comment notification | Recipient control | بدون payload حساس در email |
| Deleted source | Retention/legal policy | Tombstone و lineage مجاز |
| AI service | Approved model/data route | Prompt/output provenance |
Review بیشتر افراد را به Artifact متصل میکند؛ بنابراین سطح افشا میتواند بالا رود. «شفافیت» مجوز کپی دادهٔ Production در Ticket یا Chat نیست. Record میتواند Finding و اثر Sanitized را نشان دهد و Payload حساس را در مخزن مجاز نگه دارد.
ابزار Review چه قابلیتهایی لازم دارد؟
| قابلیت | آزمون PoC | Failure mode |
|---|---|---|
| Immutable baseline | کامنت r2 بعد از ساخت r3 هنوز بازیابی شود | Thread شناور |
| Stable locator | Field ID پس از reorder حفظ شود | کامنت روی خط اشتباه |
| Finding schema | Criterion/state/authority اجباری | متن آزاد غیرقابل گزارش |
| Diff/lineage | r2→r3 و Source تغییرکرده دیده شود | silent edit |
| Workflow | Transition نامعتبر رد شود | DONE مبهم |
| Access/retention | Reviewer فقط Scope مجاز را ببیند | افشای Evidence |
| Export/API | Finding/decision/attachments round-trip شوند | قفل فروشنده |
| RTL/Unicode | فارسی، ID لاتین و اعداد مختلط پایدار باشند | Locator شکسته |
| Offline/recovery | Export signed و merge conflict آزموده شود | از دسترفتن نظر |
نام ابزار یا تعداد Integration معیار انتخاب نیست. یک PoC با Revision، Finding و Closure واقعیِ مصنوعی اجرا کنید؛ سپس portability، availability، access، cost و failure recovery را بسنجید.
اتوماسیون چه چیزهایی را بررسی کند؟
- Schema، required field و type؛
- ID uniqueness و referential integrity؛
- Basis/Registry/Oracle/Data link availability؛
- duplicate/unknown Coverage ref؛
- Revision/digest و stale source؛
- واژگان State/Currency/Timezone؛
- PII/Secret patterns با محدودیت false positive/negative؛
- Finding state transition و required authority؛
- Resolved-without-evidence و Closure-baseline mismatch؛
- Round-trip/export loss و broken attachment.
Lint موفق فقط Ruleهای کدنویسیشده را پوشش میدهد. ابزار نمیتواند بهتنهایی معنای Domain، کفایت Oracle، نمایندگی داده، Risk consequence یا فهم کاربر را تضمین کند. نتیجهٔ analyzer باید Source، Rule version و Suppression rationale داشته باشد.
هوش مصنوعی در بازبینی Test Work Product
| کار | استفادهٔ محدود | Gate |
|---|---|---|
| پیشنهاد Finding | پرچمگذاری ambiguity/duplicate | Reviewer Observation/Criterion را تأیید کند |
| خلاصهسازی Thread | Draft rationale و unresolved points | State/decision از Record قطعی |
| Checklist tailoring | Candidate بر اساس Risk/type | Owner نسخه را تصویب کند |
| Perspective simulation | سؤالهای احتمالی | جای stakeholder واقعی نیست |
| Rework proposal | گزینهٔ متن/ساختار | Author و Domain owner بررسی کنند |
| Deduplication | Candidate clusters | Provenance و تفاوت Criterion حفظ شود |
مدل ممکن است Source، Criterion یا Locator بسازد، معنای «تومان/ریال» را حدس بزند یا دو Finding متفاوت را Merge کند. Prompt، مدل/نسخه، ورودیهای مجاز، خروجی خام، Reviewer و ویرایش نهایی را ثبت کنید. دادهٔ حساس را بدون مجوز به سرویس بیرونی ندهید و Approval را به متن روان مدل نسپارید.
نقشها را به قابلیت و Authority نگاشت کنید
| نقش/قابلیت | مسئولیت | نباید خودکار فرض شود |
|---|---|---|
| Review owner | Contract، scope، schedule و record | قبول همهٔ Findingها |
| Author | Context، response و Rework | Disposition مستقل در موارد نیازمند استقلال |
| Reviewer | خواندن Perspective و Finding | Approval/Release authority |
| Moderator | تسهیل همگرایی | مالکیت محتوا |
| Recorder/tool | حفظ State/lineage | تفسیر اثر |
| Domain/Basis owner | حل Source/Oracle question | طراحی تست کامل |
| Disposition authority | قبول/رد/تعویق طبق Policy | تغییر Fact |
| Closer | تأیید Resolution در final revision | Risk acceptance مگر صریح |
در تیم کوچک یک نفر ممکن است چند نقش داشته باشد؛ تعارض نقش را پنهان نکنید. برای Review پراثر میتوان Disposition یا Closure مستقل خواست. استقلال طیف است و هزینه/فایده و Conflict of interest باید ثبت شود.
متریکهای Review و Countermetricها
| Metric | تعریف محدود | Countermetric |
|---|---|---|
| Preparation completion | Assignmentهای تحویلشده/تخصیصیافته | زمان/عمق واقعی و copy-paste |
| Finding yield | Findingهای یکتا در واحد review | false/low-value findings |
| Duplicate rate | Findingهای Mergeشده/خام | Perspective diversity |
| Time-to-disposition | Open تا decision | premature rejection |
| Rework lead time | Accepted تا target revision | change size/regression |
| Reopen rate | Closed→Reopened | severity/missed scope |
| Escaped review pattern | نقصهای بعدی مرتبط با Criterion | attribution uncertainty |
| Criteria coverage | معیارهای assigned با statement | semantic depth |
| Perspective coverage | Perspectiveهای لازم تکمیلشده | capability/independence |
| Correction rate | Recordهای تصحیحشده | under-reporting |
تعداد Finding را KPI فردی نکنید؛ Reviewer میتواند نظرهای خرد و کمارزش بسازد و Author ممکن است Artifact دشوار را پنهان کند. «صفر Finding» نه خوب است نه بد مگر نسبت به Scope، Risk، Technique، sample و evidence تفسیر شود.
یادگیری از Review بدون ساختن قانون شتابزده
Observation pattern -> validate classification and denominator -> hypothesize cause -> inspect process/context evidence -> propose criterion/template/tool change -> pilot on bounded population -> measure benefits + countermetrics -> authorize versioned update -> monitor unintended effects
سه Finding مبهم دربارهٔ Data بهتنهایی ثابت نمیکند Template باید فیلد اجباری تازه بگیرد؛ شاید Source ownership یا آموزش Domain مسئله باشد. Findingهای Review سیگنالاند، نه علت قطعی. تغییر معیار باید برای دور بعد مؤثر شود و Review جاری را پسنگر دستکاری نکند.
ضدالگوهای رایج بازبینی تستکیس
- Approve کردن چون همهٔ فیلدها پرند؛
- Review روی «آخرین نسخه» بدون Revision؛
- ویرایش Artifact هنگام Review بدون Diff؛
- معیارهای منتشرنشده یا تغییر Gate پس از Finding؛
- یک Checklist برای Case، Charter، Script و Model؛
- برابر دانستن Trace link با Coverage؛
- پذیرفتن Reference ناشناخته/تکراری؛
- Expected result به شکل «موفق باشد»؛
- اجبار هر Reviewer به یافتن حداقل N Finding؛
- نوشتن Finding دربارهٔ شخص؛
- الزام Proposal برای معتبرشمردن Observation؛
- یکیدانستن Severity و Priority؛
- State مبهم `DONE`؛
- Self-disposition در Context نیازمند استقلال؛
- بستن Finding با پاسخ «اصلاح شد» بدون Revision/Evidence؛
- جلسه برای بلندخوانی کل Artifact؛
- حذف Finding مخالف در Deduplication؛
- سکوت Reviewer بهعنوان Approval؛
- تعویق بدون Owner، Target و Expiry؛
- تبدیل Finding سند به Product defect؛
- میانگین زمان Review بدون Risk/size/context؛
- KPI فردی بر اساس Finding count؛
- کپی PII/Token در Comment؛
- AI-generated approval بدون provenance؛
- نتیجهگیری کیفیت/Release از Review یک Sample.
Pilot سیروزه برای استقرار Review Protocol
| روز | کار | خروجی |
|---|---|---|
| ۱–۵ | انتخاب یک نوع Work Product و Risk context؛ نمونهبرداری Reviewهای قبلی | Baseline مشکلات و واژگان |
| ۶–۱۰ | تعریف ID/Revision/Basis/Criteria/Finding/State | Review Contract v0.1 |
| ۱۱–۱۵ | ساخت Fixture synthetic و تست ابزار/Export/RTL | PoC و failure log |
| ۱۶–۲۰ | Shadow review با دو Perspective و بدون حذف روش فعلی | مقایسهٔ Lineage/زمان/نویز |
| ۲۱–۲۴ | تمرین rejected/deferred/duplicate/reopened و silent edit | Workflow evidence |
| ۲۵–۲۷ | Security/privacy/access و AI boundary review | Approved data route |
| ۲۸–۲۹ | تحلیل Metric + Countermetric و مصاحبهٔ مصرفکننده | Trade-off report |
| ۳۰ | Adopt/Adapt/Stop با Scope و rollback | Decision record |
چکلیست نهایی Review owner
- Goal، decision و explicitly-not-claimed روشناند.
- Work Product type و مصرفکننده مشخص است.
- ID، Baseline revision و digest ثبت شدهاند.
- Basis/Registry/Oracle/Data snapshotها نسخهدارند.
- Scope، exclusions، population و sampling rule معلوماند.
- Risk/depth/technique تناسب دارد.
- Criteria/checklist version پیش از Review تثبیت شده است.
- Perspectiveهای لازم و assignmentها روشناند.
- Conflict of interest/independence ثبت شده است.
- Entry checks عبور یا Tailoring rationale دارند.
- هر Finding Locator و Baseline دارد.
- Observation از Consequence و Proposal جداست.
- Criterion/Evidence/Confidence ثبت شدهاند.
- Question/Suggestion/Finding/Defect تفکیک شدهاند.
- Severity/Priority/Gate effect مستقلاند.
- Duplicate merge provenance را حفظ میکند.
- State vocabulary و Transition authority معتبر است.
- Rejected/Deferred/NA rationale و expiry دارند.
- Rework در Revision تازه و Diff قابل بازیابی است.
- Resolution evidence به Finding متصل است.
- Re-review روی target/closure revision انجام میشود.
- روابط متاثر و regression بررسی شدهاند.
- Blocking finding/exception/unknown صریحاند.
- Exit Claim به sample/scope محدود است.
- Approval/Risk acceptance/Release جدا هستند.
- Recordها Secret/PII غیرمجاز ندارند.
- Automation/AI provenance و human gate دارند.
- Metricها denominator و Countermetric دارند.
- Criteria learning برای دور بعد نسخهدار میشود.
مسیر مطالعهٔ مرتبط
- نوشتن تستکیس حرفهای: طراحی و مستندسازی خود Case؛
- تحلیل نیازمندیها: سؤال از Basis و استخراج Test condition؛
- Scenario در برابر Test Case: انتخاب Artifact و سطح جزئیات؛
- تست اکتشافی ساختاریافته: Charter، Session و Debrief؛
- مستندات تست زنده: Freshness، Drift و Correction؛
- تسهیل جلسه بازبینی: Facilitation و تعارض؛
- مدیریت نقص: Product defect، Triage و Closure؛
- رهبری تضمین کیفیت: نقش و حق تصمیم.
سؤالات متداول درباره بازبینی تستکیس
۱. چه کسی باید تستکیس را بازبینی کند؟
عنوان شغلی ثابت وجود ندارد. Reviewer باید Perspective و قابلیت لازم برای Risk/Decision داشته باشد: Test design، Domain/Oracle، Automation، Operations، Accessibility یا Privacy. در تغییر کماثر یک Peer ممکن است کافی باشد؛ در Artifact پراثر چند Perspective یا استقلال بیشتر لازم است. Author میتواند مشارکت کند، اما Authority و تعارض نقش باید روشن باشد.
۲. آیا پر بودن چکلیست برای Approve کردن Test Case کافی است؟
خیر. چکلیست فقط مواردی را که صریحاً تعریف شدهاند یادآوری میکند و «غیرخالی بودن» را نباید با معنای درست یکی گرفت. Baseline، Basis، Trace، Data، Oracle، Perspective، Unknown، Finding lifecycle و Revision نهایی نیز باید متناسب با Context بررسی شوند. Checklist جامع نیست و Approval باید Claim محدود و Authority مشخص داشته باشد.
۳. تفاوت Finding بازبینی با باگ نرمافزار چیست؟
Finding نشان میدهد Work Product در Locator مشخص با Criterion/هدف Review ناهمخوان یا مبهم است. Product defect ادعایی دربارهٔ رفتار Test object است و چرخهٔ مستقل دارد. Review یک Test Case ممکن است Basis issue، Question یا Suggestion هم تولید کند. نوع رکورد را صریح کنید و فقط با Evidence مناسب بین چرخهها پیوند دهید.
۴. آیا برای هر بازبینی باید جلسه برگزار شود؟
نه. Review async با Baseline، assignment، Finding schema و Disposition روشن اغلب کافی است. جلسه زمانی ارزش دارد که اختلاف Criterion/اثر، وابستگی چندنقشی یا تصمیم همزمان وجود داشته باشد. جلسه نباید جای آمادهسازی مستقل، Finding registry، Rework revision و Closure evidence را بگیرد.
۵. هوش مصنوعی میتواند Review و Approval را خودکار کند؟
AI میتواند Finding candidate، خلاصه یا سؤال Perspective پیشنهاد کند، اما ممکن است Source، Locator و Rule را جعل یا معنا را حدس بزند. Ruleهای ساختاری را قطعی اجرا کنید، provenance مدل/ورودی/خروجی را نگه دارید، دادهٔ حساس را محافظت کنید و Finding/Disposition/Approval پراثر را به Reviewer و Authority انسانی بسپارید.
جمعبندی: Review یک چرخهٔ تصمیم است، نه کامنتگذاری
بازبینی خوب از Baseline و هدف شروع میشود، نه از تعداد Reviewer یا طول Checklist. Work Product و Sourceها را نسخهدار کنید؛ Criteria، Scope، Sampling و Perspective را پیشاپیش تعیین کنید؛ Finding را با Locator، Observation، Rule و اثر بنویسید؛ اختلاف را با Disposition و rationale حل کنید؛ Rework را در Revision تازه ثبت و Closure را روی همان نسخه بازبینی کنید. سپس Exit Claim را به Scope محدود نگه دارید. این پروتکل احتمال ابهام و گمشدن تصمیم را کم میکند، اما هرگز وعدهٔ کشف همهٔ نقصها، Coverage کامل یا کیفیت محصول نمیدهد.
