تستر در ۱۲ جلسهٔ طراحی حاضر بوده، ۳۷ سؤال پرسیده، همهٔ Wireframeها «Review شدهاند» و تیم میگوید کیفیت از ابتدا ساخته شده است. اما معلوم نیست کدام نسخهٔ Design بررسی شده، سؤالها به چه Quality Claim و Riskی وصل بودهاند، چه Findingی پذیرفته یا رد شده، چه کسی اختیار تصمیم داشته و آیا تغییر طراحی در Artifact بعدی واقعاً اعمال شده است. حضور زودهنگام بدون قرارداد Review فقط جلسه را شلوغتر میکند.
این راهنما یک Design Quality Review Loop میسازد: Decision Need → Artifact Baseline → Review Charter → Stakeholder Concern/Risk → Quality Claim → Scenario Lens → Review Question → Finding → Disposition/Design Decision → Revision → Verification → Downstream Countercheck/Correction. تمرکز مقاله «نقش تستر در بازبینی طراحی نرمافزار» است؛ نه تعریف عمومی Shift-left، نه تضمین پیشگیری از باگ و نه حق وتوی Design برای QA.
پاسخ کوتاه: تستر در بازبینی طراحی چه کاری انجام میدهد؟
تستر Concern و Risk را به Quality Claim قابلبررسی تبدیل میکند، مرز State/Interface/Data/Failure را با Scenario و Counterexample به چالش میکشد، نیاز به Observability/Controllability/Oracle را پیش از Implementation آشکار میکند و Finding را با Evidence و اثر تصمیم ثبت میکند. Author و Design authority گزینه را میسازند و تصمیم میگیرند؛ Risk owner استثنا را میپذیرد؛ تستر پس از Revision بررسی میکند که پاسخ واقعاً در Artifact تازه منعکس شده و بعداً آن را با Evidence اجرای مناسب Countercheck میکند.
- Review object: Artifact و نسخهٔ دقیق؛ نه «طراحی Feature» بهصورت مبهم.
- Quality Claim: ویژگی مورد انتظار برای Subject/Scope/Condition معین.
- Review Question: پرسشی متصل به Claim/Risk/Design element که پاسخ تصمیم را تغییر میدهد.
- Finding: Gap یا Unknown مستند؛ نه الزاماً Defect محصول.
- Disposition: تصمیم دربارهٔ Finding با rationale، owner و موعد.
- Verification: Evidence اینکه Revision یا Experiment پاسخ مصوب را اجرا کرده است.
مرز این مقاله با Shift-left عمومی چیست؟
راهنمای نقش تستر در Shift-left مالک انتخاب «زودترین نقطهٔ اقتصادی بازخورد» و اتصال Quality Question به Countercheck دیرتر است. این مقاله فقط یکی از آن Interfaceها را عمیق میکند: Review یک Design artifact پیش از یا همزمان با Implementation، از Baseline تا Finding closure. «چپ» تاریخ ثابت ندارد؛ نسبت به Feedback loop و تصمیم تعریف میشود.
Design Review با Requirement Analysis یکی نیست
| فعالیت | Object اصلی | سؤال نمونه | خروجی |
|---|---|---|---|
| Requirement analysis | نیاز، Rule، Acceptance basis | چه رفتاری و چرا لازم است؟ | Test basis/condition/gap |
| Design quality review | راهحل، Component، State، Interface، Data flow | این Design چگونه Claim را برآورده یا قابلآزمون میکند؟ | Finding/decision/revision |
| UX research | Artifact در تعامل با participant/context | کاربر چه رفتار/نیازی نشان میدهد؟ | Observation/insight/option |
| Threat modeling | Asset/trust boundary/threat/control | تهدید چگونه به Asset میرسد؟ | Security risk/control |
| Implementation test | Build/config/environment | رفتار اجراشده با Oracle سازگار است؟ | Result/finding/evidence |
تحلیل نیاز و Test Basis را راهنمای تحلیل نیازمندی برای تستر پوشش میدهد. Design Review نباید Requirement مبهم را بیصدا با فرض Reviewer پر کند؛ Gap به Basis برمیگردد.
Review با Approval و Test فرق دارد
Review میتواند Anomaly، Risk، Alternative و سؤال باز پیدا کند؛ Approval یک تصمیم سازمانی با Authority است؛ Test یک Object را با روش و Oracle بررسی میکند. Review سبز به معنی Build آماده، Testability تضمینشده یا Release مجاز نیست. Design تصمیمشده نیز ممکن است در Code غلط اجرا شود؛ Downstream countercheck لازم است.
چه Design artifactهایی قابل بازبینیاند؟
| Artifact | لنز تستر | Evidence بعدی |
|---|---|---|
| Wireframe/prototype | State، affordance، error/recovery، accessibility | prototype study/render check |
| Architecture diagram | boundary، dependency، failure propagation، observability | contract/fault/recovery test |
| API/event contract | schema، idempotency، ordering، timeout، versioning | consumer/producer contract |
| Data model/migration | invariant، identity، null/default، rollback، reconciliation | migration/reconciliation witness |
| State machine/workflow | transition، guard، terminal/retry/resume | model/state-transition tests |
| Deployment design | config، cohort، health، stop، rollback | rehearsal/canary evidence |
| Decision record | assumption، option، trade-off، expiry | validation/correction |
Artifact Baseline؛ دقیقاً چه چیزی بررسی میشود؟
Review بدون نسخه میتواند Finding را به Artifact اشتباه وصل کند. شناسه، type، version/commit، digest، owner، status، linked basis، diagram source، generated view و زمان Freeze را ثبت کنید. اگر Diagram از مدل دیگری تولید میشود، Source authoritative و زمان generation را نگه دارید؛ Screenshot صرفاً نماست.
artifact_id: DESIGN-CHECKOUT-042 type: state_and_component_design version: 6 commit: design-repo@8f31c2a digest: sha256:synthetic-design-digest status: review_candidate owner_role: checkout-design-author basis_refs: [REQ-IRR-v9, POLICY-RETRY-v3] included_views: [state-machine-v6, sequence-timeout-v4, data-contract-v2] generated_at: 2026-08-13T10:00:00+03:30 frozen_for_review_at: 2026-08-13T10:05:00+03:30
Review Charter؛ جلسه قرار است چه تصمیمی را پشتیبانی کند؟
Charter باید Objective، Decision need، Scope، excluded views، risks، review type/formality، roles، entry/exit، timebox، evidence store و not-claimed را روشن کند. «نظر QA را بگیریم» Objective نیست. نمونه: «بررسی کنیم Design v6 برای نمایش مبلغ IRR، timeout callback و duplicate event Claim و Evidence path کافی دارد یا به Revision/Experiment نیاز دارد.»
review_id: DQR-042 artifact: DESIGN-CHECKOUT-042@v6 objective: assess_claim_coverage_and_testability_before_build_commitment decision_need: ACCEPT | REVISE | EXPERIMENT | HOLD scope: [pricing-state, callback-sequence, evidence-hooks] out_of_scope: [visual-brand, production-release, legal-conformity] review_type: technical_review formality: risk_tailored entry: artifact_frozen_and_basis_available exit: all_findings_dispositioned_and_verification_planned facilitator_role: review-moderator decision_owner_role: design-owner risk_owner_role: checkout-risk-owner evidence_store: em://design-review/042/v1
سطح رسمیت را بر Risk و Object تنظیم کنید
ISTQB CTFL توضیح میدهد Review از informal تا formal متغیر است و انتخاب به Objective، SDLC، پیچیدگی، Criticality، نیاز audit و منابع بستگی دارد. Comment async روی Wireframe کمخطر ممکن است کافی باشد؛ Migration برگشتناپذیر یا Design حوزهٔ ایمنی/امنیت میتواند preparation، reviewer مستقل، checklist، entry/exit و audit trail رسمیتر بخواهد.
منبع رسمی Review چه میگوید؟
نسخهٔ رسمی ISTQB CTFL v4.0.1 نقشهای Manager، Author، Moderator، Scribe، Reviewer و Review leader را جدا میکند، Finding را تا Fix/report دنبال میکند و پذیرش Work product را به Exit criteria وصل میداند. قراردادهای تفصیلی این مقاله، توسعهٔ عملی نویسنده برای Design quality review هستند؛ فیلد رسمی ISTQB یا ادعای انطباق نیستند.
NASA چه نکتهای به Review طراحی اضافه میکند؟
راهنمای رسمی NASA دربارهٔ checklist و پیگیری Peer Review میگوید Checklist باید با نوع Work product و منظر نقشها متناسب باشد، Entry/Exit تعریف شود و Issueها تا حل و Verification دنبال شوند. این راهنما مربوط به Context مهندسی NASA است؛ الگوی این مقاله آن را بهعنوان شاهد طراحی Review discipline استفاده میکند، نه الزام عمومی یا Safety certification.
نقشها را از Job title جدا کنید
| Review role | مسئولیت | نباید |
|---|---|---|
| Author | Context، Artifact و پاسخ/Revision | Finding خود را یکنفره Close کند |
| Review leader | Objective، scope، participant و logistics | نتیجه را از قبل تعیین کند |
| Moderator | قواعد، زمان، امنیت گفتگو و تعارض | Design option را تحمیل کند |
| Reviewer/test perspective | Claim، scenario، testability و evidence gap | خود را نمایندهٔ همهٔ کاربران بداند |
| Specialist reviewer | امنیت، حریم خصوصی، دسترسپذیری، عملیات یا دامنه | خارج از صلاحیت sign-off دهد |
| Scribe | سؤال، Finding، decision و action را ثبت کند | نیت افراد را تفسیر کند |
| Decision owner | Option/Revision/Hold را تصویب کند | Risk خارج اختیار را بپذیرد |
| Verifier | Evidence closure را مستقل بررسی کند | Done تیکت را Evidence کافی بداند |
تستر نمایندهٔ خودکار کاربر نیست
تستر میتواند Scenario و Risk را از منظر Evidence به چالش بکشد، اما Experience زیستهٔ همهٔ Segmentها، تخصص UX research، Accessibility lived experience یا Domain authority را ندارد. ادعای نیاز کاربر باید به Research/Evidence وصل شود. راهنمای UX Evidence-to-Decision Observation و Insight را مالک است.
Quality Concern را از Solution جدا کنید
«Cache اضافه کنیم» Solution است؛ Concern ممکن است latency زیر بار باشد. «Retry سه بار» Solution است؛ Concern ممکن است delivery قابلاعتماد بدون side effect تکراری باشد. ابتدا Stakeholder، harm/value، operating condition و uncertainty را ثبت کنید؛ سپس Claim و Option بسازید. تستر نباید سؤال را با نسخهٔ محبوب خود پاسخ دهد.
Quality Claim قابل Review بنویسید
claim_id: QC-IDEMPOTENCY-042 property: duplicate_callback_does_not_duplicate_ledger_effect subject: payment-callback-handler-design-v6 scope: same_attempt_and_provider_event conditions: - timeout_before_response - retry_after_unknown_outcome - duplicate_and_late_delivery unacceptable: ledger_entries_for_same_effect > 1 design_refs: [sequence-timeout-v4, state-machine-v6] verification_intent: contract_plus_stateful_fault_test validity: design-v6 not_claimed: [provider_exactly_once, end_to_end_financial_correctness]
Claim باید bounded باشد. «سیستم امن/سریع/کاربرپسند است» Reviewشدنی نیست. برای Quality attribute و Measurement contract، راهنمای تست غیرعملکردی مرجع داخلی مکمل است.
Traceability گرافی بسازید
Basis/Risk → Concern → Claim → Design element → Review question → Finding → Disposition → Revision → Verification → Countercheck. این رابطهها many-to-many و نسخهدارند. جدول یکبهیک Requirement-to-Test میتواند Interface و emergent behavior را پنهان کند. Orphan Claim و Finding بدون Design ref را آشکار کنید.
| Edge | معنا | مثال |
|---|---|---|
| motivated-by | Risk/Concern دلیل Claim است | QC-42 motivated-by duplicate-effect risk |
| addressed-by | Design element ادعای پاسخ دارد | QC-42 addressed-by idempotency-key state |
| challenged-by | Question یک assumption را میآزماید | Q-7 challenges retry ordering |
| produced | Question Finding ساخته | Q-7 produced F-3 |
| dispositioned-as | Authority تصمیم داده | F-3 REVISE |
| implemented-in | Finding در Revision پاسخ گرفته | F-3 implemented-in v7 |
| verified-by | Closure Evidence دارد | F-3 verified-by diff/review/trace |
| counterchecked-by | Implementation evidence بعدی | QC-42 counterchecked-by fault-run-91 |
Scenario Lens؛ مسیر عادی کافی نیست
| لنز | سؤال Design | Evidence intent |
|---|---|---|
| Boundary | صفر/حداکثر/خارج دامنه چگونه رفتار میکند؟ | boundary/property |
| State | Transition نامعتبر و terminal state چیست؟ | state-model |
| Time | timeout، expiry، clock skew و late event؟ | virtual-time/fault |
| Concurrency | دو Writer/Request همزمان چه invariantی دارند؟ | race/witness |
| Dependency | partial/slow/wrong/duplicate response؟ | contract/fault |
| Data | identity، null، migration، retention و reconciliation؟ | data invariant |
| Permission | چه Actorی چه Actionی را میبیند/انجام میدهد؟ | authorization matrix |
| Recovery | پس از failure چگونه State فهم و ترمیم میشود؟ | recovery rehearsal |
| Operations | تشخیص، alert، runbook، rollback و owner؟ | operability check |
| Locale/access | RTL، digits، units، keyboard و assistive tech؟ | locale/accessibility evidence |
Counterexample ارزشمندتر از فهرست Edge Case است
بهجای «همه Edge caseها پوشش داده شوند»، یک invariant را بگیرید و کوچکترین مسیر نقضش را بسازید. اگر Design میگوید هر Attempt یک اثر Ledger دارد، بپرسید timeout پس از commit و پیش از response، سپس Retry با event ID متفاوت چه میکند؟ Counterexample باید precondition، sequence، state و expected property داشته باشد.
Happy Path را با State و Handoff کامل کنید
Flow chart خطی اغلب retry، cancel، resume، approval، duplicate، reversal، compensation و reconciliation را حذف میکند. برای هر handoff مالک، contract، timeout، idempotency، observable state و recovery را ثبت کنید. Diagram زیبا بدون failure semantics، Evidence design نیست.
Testability را به سه پرسش تبدیل کنید
- Controllability: آیا میتوان State/Input/Time/Dependency را امن و تکرارپذیر کنترل کرد؟
- Observability: آیا Result، State transition و side effect با هویت کافی دیده میشود؟
- Oracle: آیا Property/Expected result مستقل از Implementation قابل تعیین است؟
وجود API یا log Testability را تضمین نمیکند؛ access، determinism، correlation، privacy، retention و failure mode مهماند. طراحی کامل Testability در راهنمای تستپذیری نرمافزار آمده است.
Evidence Hook را در Design مشخص کنید
| Hook | هویت/معنا | خطر |
|---|---|---|
| Structured event | event/schema/subject/trace/time | PII/secret یا cardinality |
| State query | canonical state و freshness | backdoor Production access |
| Dependency stub/virtualization | contract/version/fault profile | fidelity drift |
| Clock control | reference time/timezone/advance | رفتار متفاوت از Production |
| Feature/config identity | flag/config/build/cohort | stale cache یا hidden override |
| Reconciliation view | source/denominator/cutoff | late event/duplicate |
Hook فقط برای QA نیست؛ Debugging و Operations نیز مصرفکنندهاند. دسترسی، minimization، retention و disable/cleanup را در Design لحاظ کنید. Test endpoint مخفی بدون auth یک «تستپذیری» ناامن است.
Oracle را از Implementation استخراج نکنید
اگر Expected amount از همان تابع Production محاسبه شود، خطای مشترک پنهان میماند. Basis، invariant، model، standard، reconciliation یا independent calculation را تعیین کنید و ambiguity را Finding کنید. طراحی Oracle و Partial/Metamorphic/Differential relations را راهنمای Test Oracle پوشش میدهد.
NFR را به صفت مبهم رها نکنید
«سریع، امن، مقیاسپذیر و کاربرپسند» Design criterion نیست. Source/stimulus/environment/artifact/response/measure/threshold و trade-off را بنویسید. Design میتواند مکانیزم پیشنهادی را نشان دهد، اما Threshold تا Measurement معتبر اثبات نمیشود. Capacity و availability نیز Context و load model میخواهند.
امنیت در Design نیازمند متخصص و Risk model است
NIST SSDF 1.1 در PW.۱/PW.۲ بر Security requirement/risk در Design و Review Design علیه آنها تأکید میکند. این مرجع نشان میدهد سؤال امنیتی باید به Requirement/Risk متصل و توسط فرد/فرایند واجدصلاحیت بررسی شود؛ حضور تستر عمومی جای Threat modeling، AppSec authority یا اثبات امنیت را نمیگیرد. این مقاله مشاورهٔ امنیتی یا انطباق نیست.
Privacy، Accessibility و Safety را به Checklist عمومی تقلیل ندهید
تستر میتواند missing consent state، retention، focus order یا hazardous fallback را سؤال کند، اما Applicability و کفایت به متخصص و Context نیاز دارد. Checklist ثابت ممکن است ریسک جدید یا گروه حذفشده را پنهان کند. Perspectiveهای تخصصی را با Authority و Evidence خود دعوت کنید و اختلاف را ثبت کنید.
Review Question Contract بسازید
question_id: DQ-042-07 claim_ref: QC-IDEMPOTENCY-042 risk_ref: RISK-DUPLICATE-EFFECT design_ref: sequence-timeout-v4#step-8 lens: time_state_dependency question: what prevents a second ledger effect after commit-before-response timeout? counterexample: - callback commits - response is lost - provider retries with new transport id evidence_needed: state_identity_and_deduplication_rule asked_by_role: test-reviewer status: OPEN
سؤال باید پاسخپذیر و به Decision مرتبط باشد. «اگر اینترنت قطع شود چه؟» بدون نقطه، State و expected property به فهرست بیپایان تبدیل میشود. Question count سنجهٔ بهرهوری نیست.
Question، Finding و Defect را جدا کنید
| Artifact | معنا | نمونه |
|---|---|---|
| Question | نیاز به توضیح/شاهد | کلید dedupe چیست؟ |
| Assumption | گزارهٔ موقت برای ادامه | provider event ID پایدار است |
| Unknown | پاسخ فعلاً موجود نیست | رفتار retry provider |
| Finding | Gap نسبت به Claim/Basis/Policy | Identity transport بهجای business effect است |
| Design defect | Design از criterion مصوب تخطی دارد | Transition duplicate effect ممکن میکند |
| Implementation defect | Build از Design/Basis معتبر منحرف است | guard در Code اجرا نشده |
| Change request | انتخاب جدید، نه اصلاح الزام موجود | نمایش تاریخچهٔ retry |
Finding Contract کامل بنویسید
finding_id: DF-042-03 review: DQR-042 artifact_ref: DESIGN-CHECKOUT-042@v6 question_ref: DQ-042-07 claim_ref: QC-IDEMPOTENCY-042 type: missing_state_identity observation: dedupe key is transport callback id gap: business effect identity is not preserved across provider retry potential_effect: duplicate synthetic ledger entry evidence_refs: [sequence-timeout-v4#8, data-contract-v2#callback_id] confidence: medium alternatives: [provider_id_stable_but_not_yet_evidenced] recommended_next: revise_identity_or_run_contract_probe status: OPEN
Potential effect را Actual defect/incident ننویسید. Severity به اثر و likelihood/exposure وابسته است؛ Priority به timing، dependency و تصمیم. Reviewer پیشنهاد میدهد؛ Authority disposition میکند.
Disposition vocabulary محدود داشته باشید
| Disposition | معنا | نیاز |
|---|---|---|
| REVISE | Artifact باید تغییر کند | owner/due/revision/verification |
| CLARIFY_BASIS | Requirement/policy مبهم است | basis owner و impact |
| EXPERIMENT | Design choice به Evidence نیاز دارد | hypothesis/guardrail/stop |
| ACCEPT_RISK | Gap باقیمانده آگاهانه پذیرفته میشود | risk authority/scope/expiry |
| DEFER | در زمان دیگری بررسی میشود | trigger/due/residual risk |
| REJECT | Finding معتبر/مرتبط دانسته نشد | rationale/evidence/appeal |
| DUPLICATE | به Finding معتبر دیگر وصل میشود | canonical ref |
| OUT_OF_SCOPE | به Route دیگری میرود | destination/owner/receipt |
Rejected Finding را حذف نکنید
ردشدن بخشی از تصمیم است. Finding، rationale، evidence و تصمیمگیر را نگه دارید تا بعداً معلوم باشد Risk دیده شده یا نه. اختلاف حلنشده را با minority note ثبت کنید؛ Consensus اجباری میتواند Signal را خاموش کند. Appeal و Reopen trigger برای Evidence تازه لازم است.
Exception و Risk Acceptance تاریخ انقضا میخواهند
«بعداً اصلاح میکنیم» Closure نیست. Scope، conditions، residual risk، compensating control، authority، due/expiry و reopen trigger را ثبت کنید. تغییر Exposure، Dependency، Policy یا Incident میتواند Exception را منقضی کند. QA بهطور پیشفرض صاحب پذیرش Business/Security/Privacy risk نیست.
Design Decision Record را به Finding وصل کنید
decision_id: DDR-042-09 finding_refs: [DF-042-03] options: - business_effect_key - provider_event_key_plus_reconciliation - no_change selected: business_effect_key rationale: stable_across_transport_retries_and_reviewable tradeoffs: [new_state_store, migration_and_retention] assumptions: [attempt_identity_available_before_callback] owner_role: design-owner risk_owner_role: checkout-risk-owner valid_for: DESIGN-CHECKOUT-042@v7 verification: diff_review_plus_contract_probe supersedes: none
Revision را با Diff و Impact بررسی کنید
Author باید Finding را به Revision دقیق وصل کند. Verifier فقط وجود متن جدید را نگاه نمیکند؛ Claim، Interface، State، Data، Error و downstream Test intent را بررسی میکند. تغییر یک Sequence میتواند Diagram دیگر، Requirement، API contract یا Testware را stale کند. Impact register بسازید.
Closure سه سطح دارد
| سطح | شرط | چیزی که ثابت نمیکند |
|---|---|---|
| Question resolved | پاسخ و evidence/ref ثبت شده | Design کافی است |
| Finding verified in design | Revision Claim را پاسخ داده | Implementation درست است |
| Claim counterchecked | Build/Environment evidence سازگار است | همهٔ Riskها یا آینده |
Review میتواند با Findingهای dispositioned منتشر شود، درحالیکه Countercheck بعدی هنوز باز است. وضعیتها را یکی نکنید؛ وگرنه «Design approved» به «Feature tested» تبدیل میشود.
Downstream Countercheck را از ابتدا طراحی کنید
برای هر Claim بگویید چه Evidence دیرتری ممکن است فرض Review را رد کند: Prototype session، static analysis، contract test، property test، fault injection، performance experiment، accessibility review، telemetry یا Production guardrail. Earliest feedback اقتصادی باید با Countercheck با fidelity بیشتر کامل شود.
Review را با Test Case workshop یکی نکنید
ممکن است Scenarioها به Condition/Case/Charter تبدیل شوند، اما هدف جلسه تکمیل Inventory تست نیست. Design choice و Evidence hook ابتدا باید روشن شوند. فهرست Test case میتواند سؤال معماری را پنهان کند یا خیلی زود روی UI فعلی قفل شود. Design review finding و test-design artifact دو lifecycle جدا اما traceable دارند.
آمادهسازی Reviewer از حضور در جلسه مهمتر است
Artifact و Context را زود بدهید، سؤالها را async ثبت کنید، Glossary و Known unknowns داشته باشید و جلسه را برای اختلاف و Decision نگه دارید. Reviewer بدون زمان preparation فقط واکنش لحظهای میدهد. Attendance صددرصدی، کیفیت Review یا تنوع perspective را ثابت نمیکند.
جلسهٔ ۶۰ دقیقهای پیشنهادی
- ۵ دقیقه: Charter، نسخه، Decision و not-claimed.
- ۱۰ دقیقه: Concern/Risk/Claim و assumptionها.
- ۱۵ دقیقه: State/Interface/Data/Failure walkthrough.
- ۱۵ دقیقه: سؤالهای ازپیشثبتشده، Counterexample و Finding.
- ۱۰ دقیقه: Option/Disposition/owner/due/verification.
- ۵ دقیقه: disagreement، open unknown، exit و next receipt.
زبان Review را از حمله به Author جدا کنید
بگویید «در v6 هویت business effect برای Retry مشخص نیست»، نه «طراحی شما به Retry فکر نکرده». Assumption در زمان Design ممکن است با اطلاعات موجود معقول بوده باشد. Blameless بودن به معنی پذیرش همه Optionها نیست؛ Finding، Authority و deadline روشن میمانند. Moderator باید قطعکردن، تمسخر و rank pressure را مدیریت کند.
همکاری تستر و توسعهدهنده یک Interface میخواهد
پرسش Review باید owner پاسخ، Channel، SLA متناسب، evidence و receipt داشته باشد؛ Pairing برای مسئلهٔ پیچیده و async comment برای سؤال ساده مناسب است. همکاری بدون خروجی قابلردیابی به حافظه وابسته میشود. الگوی Request تا Joint Evidence در راهنمای همکاری تستر و توسعهدهنده</a آمده است.
متریکهای Review با Countermetric
| Metric | تعریف | Countermetric/محدودیت |
|---|---|---|
| Entry validity | Reviewهای دارای baseline/basis / started reviews | زمان انتظار و over-formality |
| Claim coverage | Claimهای in-scope با question/evidence path | کفایت Claim و orphan risk |
| Finding disposition time | open تا receipt با percentile | premature reject/close |
| Verification rate | verified / due findings | reopen/correction rate |
| Design rework loop | revisionهای ناشی از Finding | ارزش تغییر و churn غیرمرتبط |
| Downstream surprise | Findingهای Implementation مرتبط با reviewed claim | detection opportunity و attribution |
| Review load | prep/meeting/follow-up time | decision delay و after-hours work |
Finding count KPI تستر نیست
پاداش تعداد سؤال یا Finding به nitpick، duplicate، اختلاف taxonomy و بازی با scope منجر میشود. صفر Finding نیز میتواند Design خوب، Review سطحی یا Reviewer نامناسب باشد. Outcome را در decision quality، resolved uncertainty، verification و downstream evidence ببینید؛ فرد یا تیم را رتبهبندی نکنید.
هزینه و فایدهٔ زودبودن را اندازه بگیرید
ادعای ثابت «باگ Production سی برابر گرانتر است» بدون Context، Method و Source معتبر نیست. هزینه میتواند analysis، coordination، migration، downtime، support و opportunity باشد؛ Finding اولیه نیز ممکن است false positive یا Design churn بسازد. Baseline، matched change، range و Attribution limit بنویسید. مشارکت زودهنگام زمانی ارزشمند است که انتظار کاهشیافته یا تصمیم بهتر از هزینهٔ Review بیشتر باشد.
آزمایش تکرارپذیر: حضور زیاد، Evidence کم
Fixture مصنوعی زیر ۱۲ جلسه، ۳۷ سؤال، حضور ۱۰۰٪ و Design approved را نشان میدهد و DESIGN_QUALITY_ASSURED اعلام میکند. Auditor بهجای این Dashboard، Contractهای Artifact، Charter، Claim، Question، Finding، Decision و Verification را بررسی میکند.
{
"review_id": "",
"artifact": {"id": "", "version": "", "digest": "", "type": "architecture"},
"charter": {"objective": "", "scope": "", "not_claimed": [], "review_type": "", "entry": "", "exit": ""},
"basis_refs": [],
"claims": [],
"risks": [],
"questions": [
{"id": "Q1", "claim_ref": "", "design_ref": "", "lens": "", "evidence_needed": ""}
],
"findings": [
{"id": "F1", "question_ref": "", "evidence": "", "disposition": "", "owner_role": "", "due": "", "verification": ""}
],
"authorities": {"author": "", "decision_owner": "", "risk_owner": ""},
"dashboard": {"meetings": 12, "questions": 37, "attendance_percent": 100, "approved": true},
"declared": "DESIGN_QUALITY_ASSURED"
}
const fs = require('node:fs');
const r = JSON.parse(fs.readFileSync(process.argv[2], 'utf8'));
const f = [];
const need = (ok, rule, path) => { if (!ok) f.push({ rule, path }); };
need(r.review_id, 'IDENTITY', 'review_id');
for (const key of ['id', 'version', 'digest'])
need(r.artifact?.[key], 'ARTIFACT_BASELINE', `artifact.${key}`);
for (const key of ['objective', 'scope', 'review_type', 'entry', 'exit'])
need(r.charter?.[key], 'CHARTER', `charter.${key}`);
need((r.charter?.not_claimed || []).length, 'CLAIM_BOUNDARY', 'charter.not_claimed');
need((r.basis_refs || []).length, 'BASIS', 'basis_refs');
need((r.claims || []).length, 'QUALITY_CLAIM', 'claims');
need((r.risks || []).length, 'RISK', 'risks');
for (const [i, q] of (r.questions || []).entries())
for (const key of ['claim_ref', 'design_ref', 'lens', 'evidence_needed'])
need(q[key], 'QUESTION_CONTRACT', `questions[${i}].${key}`);
for (const [i, x] of (r.findings || []).entries())
for (const key of ['question_ref', 'evidence', 'disposition', 'owner_role', 'due', 'verification'])
need(x[key], 'FINDING_CONTRACT', `findings[${i}].${key}`);
for (const key of ['author', 'decision_owner', 'risk_owner'])
need(r.authorities?.[key], 'AUTHORITY', `authorities.${key}`);
const computed = f.length ? 'HOLD' : 'READY_FOR_DESIGN_QUALITY_REVIEW';
if (r.declared !== computed) f.push({ rule: 'DECISION_MISMATCH', path: 'declared' });
console.log(JSON.stringify({ computed, count: f.length, findings: f }, null, 2));
process.exitCode = f.length ? 2 : 0;
نسخهٔ ناقص باید HOLD و ۲۷ Finding بدهد: Review identity، سه Artifact field، شش Charter/boundary، Basis/Claim/Risk، چهار Question field، شش Finding field، سه Authority و Decision mismatch. تعداد جلسه، سؤال و حضور در محاسبهٔ Readiness نقشی ندارند.
پس از ثبت DQR-۰۴۲، Artifact v6/digest، Charter و not-claimed، Basis/Risk/Claim، سؤال Q1 متصل به Design element، Finding F1 با Evidence/Disposition/owner/due/verification و سه Authority، اجرای دوباره باید count=۰ و READY_FOR_DESIGN_QUALITY_REVIEW بدهد. این فقط کاملبودن ساختار را میسنجد؛ درستی Design، Risk، Claim، Finding، Testability، امنیت یا کیفیت محصول را اثبات نمیکند.
نمونهٔ فارسی و آفلاین: Callback و مبلغ ریالی
برای Practice، یک Design ساختگی Checkout با Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation رسم کنید. مبلغ canonical را IRR و تومان را فقط presentation label قرار دهید. Scenarioهای timeout پیش/پس از commit، Retry، duplicate/late/out-of-order callback، تغییر Rule، cache stale، refund و reconciliation را به Claim و Evidence hook وصل کنید.
همهٔ نامها، شناسهها و مقادیر Fictional و آزمایش کاملاً آفلاین باشد: بدون شبکه، Production، شرکت/کاربر/پرداخت/بانک/PSP واقعی، نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، log یا Screenshot. رقم فارسی/عربی/لاتین، ی/ی، ک/ک، Unicode NFC، RTL/LTR، UTC/Asia-Tehran و تاریخ جلالی فقط نمایشی را بررسی کنید؛ ادعای حقوقی، بانکی، مالیاتی، امنیتی یا آماری ایران نسازید.
AI در Design Review چه کار کند و چه کار نکند؟
AI میتواند missing state/interface candidate، سناریوی خلاف، Trace gap، duplicate Finding، خلاصهٔ Diff و Checklist candidate بسازد. نباید Requirement/Design گمشده را جعل، Intent author را حدس، Risk را بپذیرد، Finding را خودکار Close، Security/Accessibility را تأیید یا Approval صادر کند. Artifact/source، prompt، model/version، confidence، reviewer و correction را ثبت کنید.
ضدالگوهای مشارکت تستر در طراحی
| ضدالگو | پیامد | اصلاح |
|---|---|---|
| Invite QA به همه جلسهها | بار زیاد و Objective مبهم | risk/decision-based review |
| تستر=وکیل همه کاربران | فرض نیاز و Bias | Research/specialist evidence |
| Question count=اثرگذاری | nitpick و gaming | claim/decision/verification |
| Checklist ثابت | Context و Risk تازه گم میشود | artifact/perspective-specific |
| Design approved=کیفیت | Implementation/unknown حذف | bounded result + countercheck |
| QA veto | Authority مبهم و تعارض | decision/risk map |
| همه Findingها باید Fix شوند | trade-off و capacity نادیده | bounded disposition/exception |
| Rejected finding حذف شود | حافظه و appeal از بین میرود | rationale/evidence/reopen |
| Testability endpoint مخفی | سطح حمله/نشت | auth/access/retention/design |
| ۳۰x cost guarantee | تصمیم مبتنی بر عدد بیContext | local baseline/range |
برنامهٔ Pilot سیروزه
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۳ | یک Change/Risk/Decision و Artifact را انتخاب کنید | Baseline + Charter v1 |
| روز ۴–۷ | Concern/Claim/trace/lenses را بسازید | Review packet |
| روز ۸–۱۰ | Async preparation و session | Question/Finding register |
| روز ۱۱–۱۷ | Disposition، Revision و Design verification | Decision/diff receipts |
| روز ۱۸–۲۴ | Implementation countercheck محدود | Evidence/unknown/correction |
| روز ۲۵–۳۰ | Outcome/guardrail/load review | ADOPT/ADAPT/STOP |
چکلیست Review Leader
- Artifact ID/version/digest و Source authoritative Freeze شدهاند.
- Objective، Decision، Scope، out-of-scope و not-claimed روشناند.
- Review type/formality متناسب با Risk و audit need است.
- Entry/Exit و زمان preparation تعریف شدهاند.
- Author، Moderator، Scribe، Reviewer، specialist، Decision و Risk roles روشناند.
- Concern/Risk به Claim bounded تبدیل شده است.
- Claim به Design element و Evidence intent وصل است.
- State/Time/Concurrency/Dependency/Data/Permission/Recovery/Locale lenses Tailor شدهاند.
- Questionها counterexample و evidence-needed دارند.
- Finding از Question/Unknown/Defect/Change request جداست.
- Disposition rationale، owner، due، authority و exception expiry دارد.
- Revision با Diff/Impact و Verifier مستقل بررسی میشود.
- Closure سؤال، Finding و Downstream claim جداست.
- Rejected/minority/correction history حفظ میشود.
- Metricها با Countermetric و بدون رتبهبندی فردیاند.
- AI فقط candidate میسازد و تصمیم انسانی قابلردیابی است.
جمعبندی
ارزش تستر در Design Review با زودتر وارد اتاقشدن یا بیشتر سؤالپرسیدن سنجیده نمیشود. ارزش زمانی ایجاد میشود که Concern به Claim، Claim به Design element، سؤال به Finding، Finding به Decision/Revision و Revision به Verification و Countercheck وصل شود. Review خوب عدمقطعیت و trade-off را قابل مشاهده میکند؛ محصول بینقص، هزینهٔ کمتر یا همکاری بهتر را تضمین نمیکند.
سؤالات متداول نقش تستر در بازبینی طراحی
آیا تستر باید در همهٔ جلسات طراحی حضور داشته باشد؟
خیر. بر اساس Decision، Risk، Artifact و نیاز به perspective انتخاب کنید. Review async، Pairing یا متخصص دیگر ممکن است مناسبتر باشد. حضور بدون Objective و preparation میتواند فقط هزینه و Queue بسازد.
تفاوت سؤال تستر با Finding طراحی چیست؟
سؤال درخواست توضیح یا Evidence است؛ Finding یک Gap مستند نسبت به Claim/Basis/Risk دارد. پاسخ ممکن است سؤال را بدون Finding ببندد یا نشان دهد Revision/Experiment لازم است.
آیا QA میتواند Design را رد یا تأیید کند؟
فقط اگر سازمان آن Authority محدود را صریح داده باشد. معمولاً QA Evidence، Finding و Recommendation میدهد؛ Design owner تصمیم فنی و Risk owner پذیرش Risk را در دامنهٔ خود ثبت میکند.
چگونه اثربخشی مشارکت زودهنگام را بسنجیم؟
Claim coverage، disposition/verification، resolved uncertainty، downstream countercheck و Review load را با Countermetric بسنجید. تعداد جلسه، سؤال، Finding یا ادعای عمومی کاهش هزینه بهتنهایی کافی نیست.
آیا Design Review جای تست بعد از پیادهسازی را میگیرد؟
خیر. Review بازخورد زودتر روی Artifact و assumption میدهد. Build ممکن است منحرف شود و محیط/زمان/بار رفتار تازه بسازد؛ هر Claim به Countercheck متناسب با fidelity بعدی نیاز دارد.
