جلسه بازبینی تست یک Session زماندار برای بررسی نسخهٔ مشخصی از Evidence، رسیدگی به سؤال و اعتراض، و تولید خروجی ازپیشتعریفشده است؛ نه مراسم خواندن داشبورد، شمارش باگ یا گرفتن Go/No-Go. این راهنما یک Test Review Session Contract میسازد تا ضرورت جلسه، ورودی، نقش، روش تصمیم، دسترسپذیری، Minutes و پیگیری قابلممیزی باشند.
پاسخ کوتاه: پیش از دعوت، ثابت کنید تعامل همزمان لازم است؛ Purpose و خروجی را بنویسید؛ Decision Authority و روش تصمیم را آشکار کنید؛ Evidence Pack نسخهدار با Population/Environment/Build و Unknown بفرستید؛ مشارکت را بر اساس Contribution انتخاب کنید؛ اعتراضها را ثبت و بررسی کنید؛ و نتیجه را با شرط، انقضا، Action پذیرفتهشده، Receipt و مسیر Correction ببندید. `DEFER` و `NO_DECISION` نیز میتوانند خروجی درست باشند.
مالکیت این مقاله و مرز با بازبینیهای دیگر
این صفحه فقط مالک طراحی و تسهیل یک Session بازبینی تست است. برای نقد یک Test Case یا Work Product و بستن Finding به پروتکل بازبینی تستکیس بروید. تصمیم تکنقص، Severity/Priority و Disposition در جلسه تریاژ باگ مالک مستقل دارد.
گزارش خلاصه تست مالک Evidence Snapshot و Closure Decision، ارائه نتایج تست مالک View و روایت ارائه، Sprint Review مالک بازخورد به Increment/Outcome، و گزارش پیشرفت و مانع تست مالک Update دورهای است. این مقاله جای هیچکدام را نمیگیرد.
آیا اصلاً جلسه لازم است؟
جلسه هزینهٔ هماهنگی و تمرکز دارد. اگر هدف فقط اطلاعرسانی، تأیید Receipt، جمعآوری نظر مستقل یا خواندن گزارش است، سند Async و مهلت پاسخ اغلب کافی است. Sync زمانی ارزش دارد که اختلاف تفسیر، وابستگی میان گزینهها، مذاکرهٔ محدودیت، تصمیم فوریِ چندمرجعی یا حل اعتراض به تعامل زنده نیاز داشته باشد.
| نیاز | مسیر پیشفرض | Trigger جلسه |
|---|---|---|
| Status/آمار | Update نسخهدار | تفسیر متعارض یا درخواست تصمیم |
| نظر افراد | Comment مستقل | وابستگی میان پاسخها |
| تصمیم ساده یکمرجعی | Decision Brief | اعتراض مادی یا Unknown بحرانی |
| حل چند Trade-off | Pre-read + Session | از ابتدا محتمل |
Cancel Condition را پیشاپیش بنویسید
اگر Evidence Pack تا Cutoff آماده نیست، Authority نمیتواند حاضر شود، نسخهٔ Build عوض شده یا سؤال با Comment حل شده است، جلسه باید لغو/تعویق شود. «چون در تقویم است» دلیل برگزاری نیست. لغو سالم اتلاف نیست؛ اجرای Session بیورودی اتلاف است.
Review Type را نامگذاری کنید
نوع Session میتواند `EVIDENCE_INTERPRETATION`، `RISK_REVIEW`، `OPTION_REVIEW`، `READINESS_ADVICE`، `FOLLOW_UP` یا `LEARNING_REVIEW` باشد. برچسب «Test Review» بهتنهایی نمیگوید جلسه باید چه چیزی تولید کند. چند نوع را بیدلیل در یک ساعت انباشته نکنید.
Purpose، Question و Output Contract
Purpose دلیل جلسه، Review Question پرسش محدود و Desired Output نوع نتیجه است. مثال: «آیا Evidence نسخهٔ EP-۱۷ برای انتخاب میان Rollout محدود و تعویق کافی است؟ خروجی: Advice ثبتشده به Release Authority.» همچنین `NotPromised` بگوید جلسه کیفیت محصول، امنیت، موفقیت Release یا اجماع را تضمین نمیکند.
SessionID: TRS-2026-014 Version: 1.1.0 ReviewType: READINESS_ADVICE Question: آیا Rollout مصنوعی 5% یا Evidence بیشتر توصیه شود؟ DesiredOutput: ADVICE_WITH_OPEN_ISSUES NotPromised: release approval, product quality, risk elimination
Session identity و چرخهعمر
`SessionID`، نسخه، Status، نسخهٔ جایگزینشده، Start/End برنامهریزیشده و Review time را نگه دارید. وضعیتهای نمونه: `DRAFT → DISCLOSED → READY → IN_SESSION → OUTPUT_REVIEW → CLOSED`؛ و مسیرهای `CANCELLED`، `DEFERRED`، `HOLD` و `REOPENED`. تغییر مادی Agenda یا Evidence، نسخهٔ تازه میخواهد.
Context را به Product/Release/Scope ببندید
نام «ماژول پرداخت» کافی نیست. Product/Service، Release/Build family، مسیر کاربر، Feature/State، Environment و Out-of-scope را ثبت کنید. جلسهای دربارهٔ Checkout Web نباید خودکار دربارهٔ Mobile، Production یا Settlement نتیجه بدهد.
Session Owner با Facilitator فرق دارد
Session Owner مسئول ضرورت، Contract و بستن چرخه است. Facilitator جریان مشارکت و زمان را اداره میکند و محتوا را مالک نیست. یک نفر میتواند هر دو نقش را داشته باشد، اما تعارض—مثلاً پیشنهاددهندهای که اعتراض به پیشنهاد خود را تسهیل میکند—باید افشا و برای آن Co-facilitator یا Reviewer در نظر گرفته شود.
Decision Owner و Decision Authority
Decision Owner بسته و پیگیری تصمیم را آماده میکند؛ Decision Authority حق تعهد سازمانی دارد. مدیر تست، Scrum Master، Product Owner یا Facilitator بهطور پیشفرض Authority انتشار، امنیت، بودجه یا پذیرش ریسک نیستند. اگر Session فقط Advice میدهد، آن را صریح بگویید.
روش تصمیم را قبل از بحث اعلام کنید
روش ممکن است `AUTHORITY_AFTER_ADVICE`، `CONSENT_WITH_OBJECTIONS`، `ROUGH_CONSENSUS`، `VOTE` یا `NO_DECISION/RECOMMENDATION_ONLY` باشد. هیچکدام همیشه مناسب نیست. عوضکردن روش در پایان—مثلاً تبدیل بحث مشورتی به رأی اکثریت—اعتماد و قابلیت اعتراض را از بین میبرد.
نقشهای عملیاتی جلسه
Scribe، Timekeeper، Presenter و Access Support را نامگذاری کنید. Scribe تفسیر شخصی را Fact نمیکند؛ Timekeeper حق قطع اعتراض مادی فقط به دلیل پایان Timebox ندارد؛ Access Support مشکل Caption/Platform را پیگیری میکند؛ Presenter نیز Authority نیست.
افراد را با Contribution انتخاب کنید، نه عنوان
بهجای «QA، Dev، Product و مدیر پروژه حتماً باشند»، بنویسید چه دانش، Evidence، اثرپذیری یا اختیار لازم است و چه کسی آن را نمایندگی میکند. یک توسعهدهندهٔ نامرتبط فقط تعداد نفرات را زیاد میکند؛ یک اپراتور غایب شاید اثر واقعی را بهتر بداند.
| مشارکت لازم | پرسش انتخاب | جایگزین حضور |
|---|---|---|
| منشأ Evidence | چه کسی روش/محدودیت را توضیح میدهد؟ | پاسخ Async نسخهدار |
| دانش پیامد | چه کسی اثر عملیاتی را میداند؟ | Statement نماینده |
| اختیار | چه کسی Outcome را متعهد میکند؟ | Advice و Decision بعدی |
| افراد متأثر | صدای غایب چگونه حفظ میشود؟ | Proxy با حدود آشکار |
Required، Optional و Informed را جدا کنید
Required یعنی بدون Contribution او Output معتبر نیست؛ Optional یعنی مشارکت مفید؛ Informed یعنی Receipt پس از Session کافی است. دعوت همهٔ تیم نشانهٔ شفافیت نیست. مسیر Decline/Delegate و مهلت ارائهٔ نظر Async باید وجود داشته باشد.
Power Map و صدای افراد غایب
رابطهٔ گزارشدهی، مالکیت قرارداد، ارزیابی عملکرد و تسلط زبانی بر مشارکت اثر میگذارند. مخالفت کارآموز مقابل مدیر مستقیم را «فرصت برابر صحبت» حل نمیکند. کانال خصوصی/غیرهمزمان، ترتیب صحبت بدون مقام ارشد و ثبت Affected-absent میتواند فشار را کاهش دهد؛ نه اینکه ایمنی را اثبات کند.
Evidence Pack Manifest
Session نباید چند Dashboard زنده و متغیر را مبنا بگیرد. Manifest شامل Artifact ID/version، Claim مربوط، Source/Query، `as_of`، Owner، Population، Sample، Environment، Build/Data، Fitness، Unknown، Counterevidence و Access class باشد. آنچه در جلسه نمایش داده شد باید بعداً بازسازی شود.
EvidencePack: EP-TRS-014@2.0.1 AsOfUTC: 2026-08-13T08:00:00Z Population: synthetic scenarios S01..S24 Environment: local disconnected stub E-4 Build: B-17; DataPack D-09 Unknown: callback order outside fixture Counterevidence: EV-19, EV-22 AccessClass: INTERNAL-SYNTHETIC
Metricهای خام «واقعیت» نیستند
Pass rate، تعداد Bug، Coverage، Defect Density و Escape فقط با Denominator، Window، Population، Severity policy، Exclusion و Data fitness قابلتفسیرند. «۳۰٪ شکست و پنج نقص بحرانی که مستقیماً بر درآمد اثر دارد» بدون این زنجیره، Fact واحد نیست و رابطهٔ علّی را ثابت نمیکند.
Unknown و Counterevidence در صفحهٔ اصلی
ناشناختهها و خلافشواهد را به Appendix آخر نبرید. برای هر Unknown بنویسید چه تصمیمی را محدود میکند و چه کسی آن را دنبال میکند. نبود Evidence سبز نیست. مخالفِ Claim باید به همان اندازهٔ موافق آن زمان و مسیر بررسی داشته باشد.
Pre-read با عدد ثابت ۲۴ ساعت تعریف نمیشود
زمان ارسال را از حجم، پیچیدگی، زبان، Accessibility need، اهمیت تصمیم و دسترسبودن افراد تعیین کنید. فایل کوتاه شاید چند ساعت و بستهٔ حساس شاید چند روز بخواهد. `sent_at`، Reading time تخمینی، Cutoff سؤال و Material changes را ثبت کنید؛ «ارسال شد» اثبات خواندهشدن یا فهم نیست.
Agenda Contract بهجای فهرست موضوع
هر Item باید Owner، پرسش، پیشنیاز، Priority، Timebox و Output type داشته باشد: `INFORM / CLARIFY / ADVISE / DECIDE / ASSIGN / DEFER`. «مرور باگها—۲۰ دقیقه» نه پرسش دارد نه خروجی. موضوع بیپیشنیاز از Agenda حذف شود.
| Item | Question | Output | Fallback |
|---|---|---|---|
| A1 | Oracle اختلاف دارد؟ | CLARIFY | Evidence request |
| A2 | اعتراض O-۳ مادی است؟ | ADVISE | DEFER |
| A3 | Option B توصیه شود؟ | DECIDE/ADVISE | NO_DECISION |
Timebox مرز توجه است، نه ماشین حذف مسئله
Timebox کمک میکند اولویت دیده شود؛ اعتراض مادی با رسیدن دقیقهٔ بیستم باطل نمیشود. Facilitator میتواند Timebox را تمدید، Item کماولویت را جابهجا یا Output را `DEFER` کند. ثبت دلیل تغییر مهمتر از اطاعت کور از Agenda است.
Parking Lot باید مالک و موعد داشته باشد
Parking بدون Owner/Due قبرستان سؤال است. هر مورد باید دلیل خروج از Scope، اثر احتمالی بر تصمیم، Route، Owner، Due و پیوند به Issue داشته باشد. اگر موردی میتواند Outcome جاری را تغییر دهد، Park کردن آن مجاز نیست؛ Session باید HOLD یا DEFER شود.
دسترسپذیری بخش حاکمیت جلسه است
راهنمای W3C دربارهٔ دسترسپذیری جلسات Remote/Hybrid انتخاب Platform، دسترسی به محتوا و تعامل را مسئلهٔ طراحی جلسه میداند. این سند W3C یک راهنمای قابلانطباق است، نه استاندارد اجباری جلسهٔ QA یا اثبات انطباق دسترسپذیری.
Platform check پیش از روز جلسه
Keyboard navigation، Caption، Screen reader، Dial-in، Chat، Share، دسترسی مهمان و کیفیت اتصال را با نیاز واقعی افراد آزمایش کنید. «Zoom/Meet داریم» کافی نیست. یک مسیر تماس برای رفع مانع و یک Plan B متنی/صوتی داشته باشید.
Caption، متن جایگزین و RTL/LTR
Caption خودکار ممکن است اصطلاح فنی و فارسی را غلط بگیرد؛ مسئول Correction یا Transcript review تعیین کنید. نمودار باید جدول/خلاصهٔ متنی داشته باشد. ترکیب شناسهٔ لاتین، عدد و متن فارسی با Direction مناسب نمایش داده شود تا Evidence ID یا مبلغ وارونه نشود.
Hybrid parity را طراحی کنید
مشارکتکنندهٔ Remote نباید صدای درجهدو باشد. Chat و دست بلندشده را کسی پایش کند؛ Artifact برای همه همزمان قابلدسترسی باشد؛ گفتوگوی داخل اتاق تکرار شود و تصمیم در Whiteboard فیزیکی محبوس نماند. راهنمای رسمی GOV.UK برای کانالهای ارتباطی فراگیر نیز بر تنوع کانال و محدودنکردن Agenda تأکید میکند؛ اینجا فقط بهعنوان اصل قابلانطباق استفاده میشود.
مسیر Async و Break
فردی که نمیتواند سریع صحبت کند یا Session طولانی را ادامه دهد باید بتواند Comment نسخهدار بدهد. زمان Break با طول، نیاز Caption/Interpreter و بار شناختی تنظیم شود. غیبت یا استفاده از مسیر Async نشانهٔ مشارکت کم نیست و نباید وارد ارزیابی فرد شود.
Recording، Consent و Retention
ضبط پیشفرض نباشد. Purpose، افراد دارای دسترسی، Retention، نحوهٔ اعتراض و جایگزین شرکت بدون ضبط را قبل از شروع روشن کنید. Transcript خام میتواند PII، Credential یا اطلاعات حساس داشته باشد. Minutes تصمیممحور غالباً از ضبط کامل کمخطرتر است؛ اما تصمیم حقوقی/حریم خصوصی را متخصص مربوط میگیرد.
Working Agreement کوچک و عملی
Normها را به رفتار قابلمشاهده تبدیل کنید: نقد Claim نه شخص؛ یک Conversation؛ منبع را نام ببرید؛ Unknown مجاز؛ تعارض افشا؛ اعتراض بدون تلافی؛ Pause قابلدرخواست؛ و تصمیم/عدمتصمیم ثبت میشود. شعار «مثبت باشیم» از مخالفت سازنده محافظت نمیکند.
No-blame یعنی حذف پاسخگویی نیست
تمرکز سیستممحور مانع بررسی انتخاب، نقش یا نقض کنترل نمیشود. No-blame نباید برای خاموشکردن گزارش رفتار آسیبزا استفاده شود. Fact، Context، Decision right و Action را جدا ثبت کنید؛ موضوع انضباطی/حقوقی را در Session عمومی حل نکنید.
Opening در پنج قرارداد کوتاه
- Purpose/Question/Out-of-scope را بازگو کنید.
- Evidence Pack version و Material change را تأیید کنید.
- Role/Authority/Decision method را نام ببرید.
- Norm، Accessibility، recording و Pause route را مرور کنید.
- بپرسید آیا مانع مادی برای شروع وجود دارد؛ سکوت را Consent ندانید.
یک نسخهٔ مشترک از مسئله بسازید
پیش از Option، Facilitator از افراد میخواهد Scope، Claim اصلی، Unknown و Decision need را با زبان خود بازگو کنند. این Comprehension Check رأی یا آزمون حافظه نیست. اختلاف برداشت باید به Issue تبدیل شود؛ نه اینکه فرد «جلسه را کند کرده» تلقی شود.
Turn design و سکوت
Round-robin اجباری ممکن است فرد را در معرض فشار بگذارد؛ گفتوگوی آزاد نیز صدای پرقدرت را غالب میکند. ترکیبی از نوشتن مستقل، دعوت اختیاری، Round محدود، Chat/anonymous question و زمان فکر استفاده کنید. «افراد ساکتتر را مجبور به نظر دادن» معیار مشارکت فراگیر نیست.
پرسش تسهیلگر باید خنثی و قابلپاسخ باشد
بهجای «همه موافقاند که Release امن است؟» بپرسید: «کدام Claim برای Option A کافی نیست؟ چه Evidence یا شرطی اعتراض را پاسخ میدهد؟» پرسش نباید نتیجهٔ مطلوب، مقام یا قضاوت شخص را در خود حمل کند.
Issue و Objection Register
هر اعتراض با `IssueID`، Claim/Option مربوط، دلیل، Evidence، شدت پیامد، پاسخ، Disposition، Owner و Reopen condition ثبت شود. عبارت «Dev مخالف بود» دلیل نیست. فرد میتواند نظرش را تغییر دهد ولی Issue فنیِ پاسخندادهشده خودکار ناپدید نمیشود.
IssueID: O-03 Against: OPTION-B Reason: callback ordering outside Population is unknown Evidence: EV-22@1.0 Disposition: DEFER_FOR_EVIDENCE Owner: ROLE-QA-07 DueUTC: 2026-08-16T09:00:00Z Reopen: new Build or contradictory replay
Consensus شمارش دستها نیست
RFC ۷۲۸۲ دربارهٔ Consensus و Humming در IETF توضیح میدهد که رأینمایی یا شمارش صداها جای رسیدگی به ماهیت اعتراض را نمیگیرد و یک اقلیت با اعتراض فنی معتبر را نمیتوان با اکثریت خام حذف کرد. این RFC Informational دربارهٔ فرآیند IETF است؛ نسخهٔ حاضر آن را قانون عمومی همهٔ تصمیمهای QA نمیخواند، بلکه از منطق objection-aware آن استفاده میکند.
Consent، Consensus، Advice و Vote را مخلوط نکنید
| روش | پرسش | ریسک |
|---|---|---|
| Advice | چه توصیهای به Authority میدهیم؟ | توصیه بهجای تصمیم ثبت شود |
| Consent | اعتراض مادیِ حلنشده هست؟ | تسلیم بهجای رضایت |
| Rough consensus | Issueها واقعاً رسیدگی شدهاند؟ | Headcount و خاموشکردن اقلیت |
| Vote | قاعده و Electorate چه بود؟ | رأی بدون صلاحیت/زمینه |
| Authority | پس از Advice چه تصمیمی میگیرد؟ | مقام بهجای استدلال |
Humming، Emoji و Poll فقط Signal آغاز بحثاند
Poll میتواند دمای اتاق یا نقطهٔ شروع را نشان دهد؛ Proof توافق نیست. افراد Remote، افراد کمقدرت یا کسانی که سؤال را متفاوت فهمیدهاند ممکن است دیده نشوند. نتیجهٔ Poll را با Population/Question/Abstention ثبت و سپس دلیل اعتراض را بررسی کنید.
Dissent را حفظ کنید
تصمیم ممکن است برخلاف ترجیح یک نفر گرفته شود. Dissent باید Claim، دلیل، Evidence، پاسخ Authority و Appeal route داشته باشد. «مخالف بود اما اکثریت موافق بودند» رسیدگی نیست. ثبت مخالفت، فرد را مالک نتیجه یا مانع همکاری نمیکند.
NO_DECISION و DEFER خروجی معتبرند
نسخهٔ قدیمی هر جلسهٔ بیتصمیم یا Action را ناموفق میدانست. گاهی بهترین خروجی تشخیص نبود Authority، Evidence ناکافی، تعارض حلنشده یا Scope اشتباه است. `NO_DECISION` باید دلیل و Route داشته باشد؛ تصمیم ساختگی برای «نتیجهگرا بودن» خطرناکتر است.
Decision Record شرطی و منقضی
Outcome، Authority، روش، Rationale، Evidence version، Conditions، Unknowns، Dissent، Expiry و Reopen Trigger را ثبت کنید. `GO` بدون Scope، Build و Guardrail تصمیم نیست. Session ممکن است فقط `ADVICE` ثبت کند و Decision Record جداگانه بعداً ساخته شود.
Outcome: DEFER Method: AUTHORITY_AFTER_ADVICE Rationale: O-03 affects rollback interpretation EvidencePack: EP-TRS-014@2.0.1 Unknowns: UNK-04 Dissent: DS-02 retained ExpiresAtUTC: 2026-08-20T09:00:00Z ReopenTrigger: EV-27 accepted
Action Item باید پذیرفته شود
نامنوشتن کنار Action پذیرش نیست. Owner باید Scope، Due، ظرفیت، Dependency و Done Evidence را تأیید کند. Action بدون Capacity check تعهد نمایشی میسازد. Facilitator یا مدیر پروژه مالک پیشفرض همهٔ Follow-upها نیست.
| فیلد Action | نمونه | ضدالگو |
|---|---|---|
| Accepted owner | ROLE-QA-07 | «تیم QA» |
| Due | UTC + View تهران | ASAP |
| Done evidence | Replay R-29 + Oracle diff | بررسی شود |
| Dependency | Stub B-18 | پنهان |
Minutes رونوشت مکالمه نیست
Minutes باید Context، Evidence versions، تصمیم/Advice، Rationale، Open issue، Dissent، Action، Parking و تاریخ Review را نگه دارد. انتساب نقلقول فقط در صورت نیاز و با Review مناسب. «بحث شد» یا «همه همسو شدند» قابلممیزی نیست.
Minutes همان روز قانون جهانی نیست
سرعت مهم است، اما پیچیدگی و Review window نیز مهماند. Draft فوری با وضعیت `UNCONFIRMED` میتواند مفید باشد؛ نسخهٔ تأییدشده بعداً میآید. Deadline را در Contract تعیین کنید. ارسال سریعِ صورتجلسهٔ غلط از ارسال دیرترِ قابلبررسی بهتر نیست.
Receipt و پنجرهٔ بازبینی
گیرندگان باید بتوانند بگویند Minutes تصمیم یا مخالفت آنها را درست بازتاب نمیدهد. Receipt یعنی دریافت/برداشت، نه تصدیق حقیقت Evidence یا موافقت با Outcome. پایان Review window سکوت را به توافق تبدیل نمیکند؛ فقط نسخه را طبق Policy جاری میکند.
Correction و Reopen
عدد غلط، نقش Authority اشتباه، Evidence تازه یا Dissent حذفشده باید Correction نسخهدار بسازد و تصمیمهای متأثر را علامت بزند. تاریخچه حذف نشود. Reopen Trigger ممکن است Build جدید، خلافشواهد، نقض Condition یا گذشت Expiry باشد.
Follow-up دو حلقه دارد
حلقهٔ اول Action/Decision Outcome را بررسی میکند؛ حلقهٔ دوم خود Session را: آیا ورودی کافی، مشارکت قابلدسترسی، روش تصمیم روشن و Minutes درست بود؟ رضایت شرکتکننده یک Signal است، نه اثبات کیفیت Session. هر دو حلقه Owner و Window جدا داشته باشند.
Metricهای مناسب جلسه
درصد Item دارای Output، زمان تا پاسخ Issue، Action acceptance، Correction latency، Evidence-version coverage، Accessibility incident و Reopen rate میتوانند Signal باشند. تعداد کلمات هر فرد، روشنبودن دوربین، حضور، تأخیر یا «مقاومت» برای امتیازدهی افراد استفاده نشود؛ `people_scoring=false`.
قالب کامل Session Contract
[Identity] SessionID, Version, Status, Supersedes, Start/End, ReviewAt [Context] Product, Release, Scope, OutOfScope [Necessity] SyncReason, AsyncAlternative, CancelCondition [Purpose] ReviewType, Question, DesiredOutput, NotPromised [Governance] Owner, Facilitator/Conflict, Authority, Method, Scribe/Access [Participants] SelectionRule, Contribution, AffectedAbsent, Power, Decline [Inputs] Manifest/Version/AsOf, Provenance, Population, Environment, Build [Evidence] Fitness, Unknown, Counterevidence, AccessClass [PreRead] SentAt, ReadingTime, MaterialChange, QuestionRoute [Agenda] Item, Owner, OutputType, Timebox, Prerequisite, Priority [Access] Platform, Keyboard, Captions, Text, RTL/LTR, Async, Breaks [Privacy] RecordingConsent, Minimization, Retention, AccessControl [Conduct] Norms, NoBlame, NoRetaliation, PauseRoute [Facilitation] TurnDesign, ChatParity, Comprehension, ParkingOwner/Due [Issues] Register, ObjectionReason, Disposition, Dissent, Appeal [Decision] Outcome, Rationale, Conditions, Unknown, Expiry, Reopen [Actions] AcceptedOwner, Due, Capacity, DoneEvidence, Followup [Minutes] EvidenceVersions, Decisions, Issues, Actions, Review, Receipt, Correction [Followup] OutcomeReview, SessionReview, Countermetrics, AuditTrail [Limits] people_scoring=false, NotProof
آزمایشگاه آفلاین Checkout ایرانی
Fixture خیالی `SYN-TEST-REVIEW-SESSION-۰۱` یک Checkout کاملاً جدا از شبکه و Production دارد: Order/PaymentAttempt جعلی، PSP Stub، Callback، Ledger، Reconciliation و اعلان ساختگی. Timeout پیش/پس از Fake Commit، Retry، Callback تکراری/دیر/جابجا و State مبهم در Build و Data Pack ثابت بازپخش میشوند.
شناسههای Tenant/Order/Attempt/Event/Run/Build/Data/Evidence/Issue/Session/Decision پایدارند. مبلغ فقط IRR خیالی و تومان صرفاً نمایش برچسبخورده است. ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، ZWNJ، RTL/LTR، UTC، نمای Asia/Tehran و جلالی صرفاً Presentation پوشش داده میشوند. هیچ شبکه، سازمان، فرد، کاربر، سفارش، پرداخت، PSP، بانک، پول، PII، نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Log یا Screenshot واقعی و هیچ توصیهٔ مالی/بانکی/حقوقی/امنیتی/حریم خصوصی/منابع انسانی وجود ندارد.
Checker سطحی چگونه فریب میخورد؟
Checker فقط شروع سر وقت، Pre-read بیستوچهارساعته، حضور Manager/Product/Dev/QA، نمایش Dashboard، Parking Lot و ارسال Minutes همان روز را میبیند و نتیجه میدهد:
superficial: MEETING_EFFECTIVE
هیچیک ضرورت Sync، نسخهٔ Evidence، اختیار، دسترسپذیری، ماهیت اعتراض یا پذیرش Action را ثابت نمیکند.
ممیزی ساختاری چه یافت؟
اجرای نخست Validator شفافاً mismatch طراحی را نشان داد: ۹۸ Finding واقعی در برابر انتظار ۱۰۱. شمارنده تغییر نکرد؛ سه کنترل ماهوی Population، Environment و Build به Evidence Contract افزوده شد. اجرای نهایی:
audit: HOLD-101 independentPeopleScoringRule: PASS
قاعدهٔ ۱۰۲ مستقل است و `people_scoring=false` را کنترل میکند. عدد ۱۰۱ فقط تعداد کنترلهای غایب در همین Fixture و نسخه است؛ Benchmark جلسه یا امتیاز سازمان نیست.
نسخهٔ اصلاحشده چه میگوید؟
corrected: READY_FOR_TEST_REVIEW_SESSION-0
صفر یعنی Contract این Validator کامل است؛ نه اینکه Evidence درست، Inclusion واقعی، Consensus معتبر، Action انجامشده، کیفیت محصول، ایمنی Release، Outcome یا درستی تصمیم ثابت شده باشد. Judgment و Review انسانی باقی میماند.
ضدالگوهای جلسه بازبینی تست
- برگزاری چون جلسه تکرارشونده است.
- خواندن Status بهجای تعامل لازم.
- دعوت نقشها بدون Contribution.
- اجباریکردن حضور همهٔ QA/Dev/Product.
- فرض Authority از عنوان شغلی.
- Facilitator ذینفع بدون افشای Conflict.
- Dashboard زنده بدون Snapshot/version.
- Pass rate و Bug count بدون Denominator.
- پنهانکردن Unknown/Counterevidence.
- Pre-read ثابت ۲۴ ساعت برای هر بسته.
- Agenda موضوعی بدون Question/Output.
- حذف اعتراض با پایان Timebox.
- Parking بدون Owner/Due.
- اجبار افراد ساکت به صحبت عمومی.
- بیاعتنایی به Chat و افراد Remote.
- ضبط پیشفرض و Retention نامعلوم.
- «No blame» برای حذف پاسخگویی.
- Poll/Emoji/تشویق بهعنوان Consensus.
- اکثریت خام علیه اعتراض فنی باز.
- تسلیم خستهشده بهعنوان Consent.
- ساخت Decision فقط برای نتیجهگرا بودن.
- Action تحمیلی بدون پذیرش/ظرفیت.
- Minutes با عبارت مبهم «بحث شد».
- سکوت در Review window بهعنوان Agreement.
- ویرایش خاموش Minutes یا Evidence.
- امتیازدهی حضور، دوربین، حرفزدن یا مخالفت.
- ادعای بهبود قطعی کیفیت/فرهنگ از جلسه.
- استفاده از AI بهعنوان Scribe بیReview یا Authority.
چکلیست Session Owner
- SessionID/version/status و زمانها ثبتاند.
- Sync reason، Async alternative و Cancel condition روشناند.
- Review type، Question، Output و Not-promised نوشته شدهاند.
- Product/Release/Scope/Out-of-scope دقیقاند.
- Owner، Facilitator/Conflict، Authority و Method معلوماند.
- Scribe، Timekeeper و Access support تعیین شدهاند.
- شرکتکنندگان با Contribution و Power انتخاب شدهاند.
- Affected-absent، Decline و Async route وجود دارد.
- Manifest/version/as-of/provenance قابلردیابی است.
- Population/Environment/Build/Fitness ثبتاند.
- Unknown/Counterevidence در بستهٔ اصلیاند.
- Pre-read زمان کافی و Material-change disclosure دارد.
- هر Agenda item پرسش، Output، Owner و fallback دارد.
- Platform/Keyboard/Caption/Text/RTL-LTR بررسی شدهاند.
- Recording consent/Minimization/Retention/Access روشناند.
- Norm، no-retaliation و Pause route عملیاند.
- Turn design، Chat parity و Comprehension check طراحی شدهاند.
- Parking Owner/Due و اثر بر تصمیم دارد.
- Objection reason/Disposition/Dissent/Appeal حفظ میشوند.
- Outcome/Rationale/Condition/Expiry/Reopen ثبت میشوند.
- Action فقط با Accepted owner/capacity/done evidence ساخته میشود.
- Minutes نسخههای Evidence، Issue و Correction route دارد.
- Outcome review و Session review جدا هستند.
- `people_scoring=false` مستقل کنترل شده است.
- NotProof حدود نتیجه را صریح میگوید.
Pilot سیروزه برای بهبود Sessionها
- روز ۱ تا ۵: یک جلسهٔ کمخطر را انتخاب و بررسی کنید آیا Async جایگزین کافی است؛ Contract را در Shadow بسازید.
- روز ۶ تا ۱۰: Evidence Manifest، Population/Build، Unknown و Participant Contribution را ثبت کنید.
- روز ۱۱ تا ۱۵: Agenda خروجیمحور، Accessibility check، Method و Objection Register را Dry-run کنید.
- روز ۱۶ تا ۲۰: Session را با مسیر Async/Chat parity اجرا و `DEFER/NO_DECISION` را مجاز نگه دارید.
- روز ۲۱ تا ۲۵: Minutes/Receipt/Correction و Action acceptance را ببندید؛ افراد را ارزیابی نکنید.
- روز ۲۶ تا ۳۰: Outcome و Session loop را با Countermetric مرور و Continue/Adapt/Stop تصمیمگیری کنید.
Pilot اثبات نمیکند Session باعث کیفیت یا سرعت شده است. تغییر همزمان تیم، Build، Scope و ابزار را بهعنوان Alternative حفظ کنید.
جمعبندی
جلسه بازبینی تست وقتی ارزش دارد که تعامل زنده برای یک Question محدود لازم باشد. Session را با هویت، Evidence نسخهدار، Contribution، Authority، روش تصمیم، دسترسپذیری و اعتراض طراحی کنید؛ `DEFER` را شکست ندانید؛ Action را تحمیل نکنید؛ و Minutes را با Receipt، Expiry و Correction ببندید. تقویم، حضور مدیر و داشبورد جای این قرارداد را نمیگیرند.
پرسشهای متداول جلسه بازبینی تست
جلسه بازبینی تست چیست؟
Session زمانداری برای بررسی نسخهٔ مشخص Evidence و تولید Output معلوم—مانند Clarification، Advice، Decision یا Evidence Request—است. این جلسه با بازبینی تستکیس، تریاژ باگ، Sprint Review و Test Summary تفاوت دارد.
چه کسانی باید در جلسه بازبینی تست باشند؟
افرادی که Contribution لازم دارند: منشأ Evidence، دانش پیامد، افراد متأثر یا Authority. عنوان QA/Dev/Product بهتنهایی حضور را اجباری نمیکند. Required، Optional و Informed را جدا و برای غایبان مسیر نمایندگی/Async فراهم کنید.
چه معیارهایی را در جلسه بازبینی تست نشان دهیم؟
فقط Metricهایی که به Review Question مربوطاند و Contract کامل دارند: Population، Denominator، Window، Build/Environment، Source، Fitness، Unknown و Counterevidence. فهرست ثابت Coverage، Pass rate، Bug count، Density و Escape برای همهٔ جلسهها معتبر نیست.
چگونه تنش جلسه بازبینی تست را مدیریت کنیم؟
Power/Conflict را پیشاپیش ببینید؛ Claim را از شخص جدا کنید؛ No-retaliation، Pause و مسیر خصوصی/Async بدهید؛ اعتراض را با دلیل و Evidence ثبت کنید؛ و موضوع رفتاری/حقوقی را در Route مناسب ببرید. «مثبت باشیم» یا قطع بحث، حل تنش نیست.
اگر جلسه به تصمیم نرسید ناموفق است؟
نه. اگر Authority غایب، Evidence ناکافی، اعتراض مادی باز یا Scope اشتباه باشد، `DEFER` یا `NO_DECISION` خروجی سالم است؛ به شرط اینکه دلیل، Owner، Evidence request، Due و Reopen route ثبت شود. تصمیم نمایشی برای بستن جلسه خطرناک است.
