منشور تست اکتشافی؛ قالب Session و Debrief

منشور «Checkout را کامل تست کن» آزادی نمی‌دهد؛ ابهام می‌دهد. تستر ممکن است ۹۰ دقیقه بین صفحه‌ها بچرخد، چند Screenshot بگیرد و در پایان نتواند بگوید کدام ریسک را بررسی کرده، چه چیزی را ندیده و چرا نتیجه برای انتشار مهم است.

در مقابل، یک منشور تست اکتشافی خوب Mission می‌سازد: «چرخهٔ پرداخت سفارش را هنگام Timeout پس از Commit و Callback تکراری، با PSP شبیه‌سازی‌شده و مشاهدهٔ Order/Ledger/Outbox بررسی کن تا ناسازگاری مالی یا رفتار غیرقابل‌بازیابی را کشف کنی.» این جمله مسیر می‌دهد، اما Test را به گام‌های ازپیش‌نوشته‌شده زندانی نمی‌کند.

پاسخ کوتاه: Test Charter یک مأموریت کوتاه و قابل‌مذاکره برای یک Session اکتشافی است. Charter باید هدف/ریسک، Target و مرز، منابع و Tactic، Oracle، محدودیت/ایمنی، Timebox و Evidence مورد انتظار را روشن کند. خروجی Session فقط Bug نیست؛ Observation، سؤال، مدل، Coverage note، Test idea، Risk update و تصمیم Follow-up است. ارزش Charter در چرخهٔ ریسک و سؤال → Mission → Session و یادگیری → Evidence → Debrief → تصمیم و Charter بعدی شکل می‌گیرد.

منشور تست اکتشافی چیست؟

منشور، Mission یک فعالیت تستی است؛ توضیح می‌دهد کدام بخش محصول را با چه نگاه و منابعی بررسی کنیم و چه نوع اطلاعاتی می‌خواهیم به دست آوریم. Charter «Test Case سبک» نیست و قرار نیست همهٔ Clickها، داده‌ها و Expected Resultها را از قبل مشخص کند. اگر مسیر کامل از قبل نوشته شده باشد، فضای یادگیری و تغییر مسیر کم می‌شود.

سیلابس رسمی ISTQB CTFL ۴.۰.۱ تست اکتشافی را طراحی، اجرا و ارزیابی هم‌زمان هنگام یادگیری محصول تعریف می‌کند و Session-based testing را با Timebox، Charter دارای هدف، Session sheet و Debrief توضیح می‌دهد. این اجزا یک نسخهٔ اجباری جهانی نیستند، اما برای ساخت Accountability مفیدند.

منشور چه چیزی نیست؟

چک‌لیست کامل همهٔ رفتارهای محصول نیست.
تضمین «پوشش کافی» یا کشف Defect نمی‌دهد.
مجوز تست بی‌هدف یا بدون یادداشت نیست.
جایگزین Regression خودکار، تست تکنیکی یا Review نمی‌شود.
سند ثابت و تغییرناپذیر نیست؛ با یادگیری می‌تواند مذاکره یا شکسته شود.
گزارش نتیجه نیست؛ Mission قبل از کار است و Session report داستان آنچه واقعاً رخ داده.

مبانی Test Design هم‌زمان، Session، Heuristic و ثبت شواهد در مقالهٔ تست اکتشافی ساختاریافته پوشش داده شده است؛ این مقاله روی طراحی و ادارهٔ Charter عمیق می‌شود.

Charter، Test Case، Checklist و Test Plan چه تفاوتی دارند؟

Artifact	پرسش اصلی	سطح پیش‌تعریف	خروجی مورد انتظار
Test Charter	چه Mission اطلاعاتی را در این Session دنبال کنیم؟	هدف/مرز/نگاه؛ مسیر در حین یادگیری ساخته می‌شود.	یادگیری، Evidence، یافته و Follow-up
Test Case/Procedure	این شرایط و گام‌ها چه نتیجهٔ مشخصی باید بدهند؟	ورودی، گام و انتظار بیشتر از قبل مشخص‌اند.	رأی Pass/Fail قابل تکرار برای Case
Checklist	کدام یادآورها نباید از قلم بیفتند؟	فهرست Condition/موضوع؛ معمولاً بدون مسیر کامل	یادآوری و Evidence پوشش موارد
Test Plan/Strategy	کل تلاش تست با چه Scope، منابع، ریسک و زمان اداره شود؟	سطح پروژه/محصول/Release	هماهنگی و تصمیم کلان
Bug report	کدام رفتار مشاهده‌شده چرا مشکل است و چگونه بازتولید می‌شود؟	پس از مشاهدهٔ Anomaly	تصمیم و اقدام روی مشکل

این Artifactها رقیب نیستند. یک Session می‌تواند از Checklist امنیتی استفاده کند، Bug report بسازد و برای یک Regression پایدار Test خودکار پیشنهاد دهد.

Session-Based Test Management یا SBTM چیست؟

SBTM راهی برای مدیریت کار اکتشافی با Sessionهای Charterدار، Timebox، یادداشت، Review و Reporting است. هدف، تبدیل تستر به ماشین اجرای Template نیست؛ قابل‌مشاهده‌کردن کار فکری و موانع آن است. یک پژوهش دانشگاهی دربارهٔ سطوح تست اکتشافی نیز نشان می‌دهد درجهٔ اکتشاف با شیوهٔ صورت‌بندی Charter ارتباط دارد و ترکیب سطح‌های مختلف می‌تواند مفید باشد؛ پس Charter باید با Context تنظیم شود، نه اینکه یک نسخه برای همه تحمیل شود.

چرخهٔ عملی SBTM

Intake/Risk: سؤال، تغییر، Incident یا نگرانی Stakeholder جمع شود.
Charter: Mission با Tester و ذی‌نفع مذاکره شود.
Setup: Build، Environment، Data، Tool و ایمنی آماده شوند.
Session: Tester یاد می‌گیرد، مدل می‌سازد، آزمایش می‌کند و مسیر را تطبیق می‌دهد.
Notes/Evidence: Observation، سؤال، Bug، Coverage و زمان/مانع ثبت شود.
Debrief: محصول، تست، Coverage، یافته و Next step مرور شود.
Backlog: Bug، Question، Automation idea، Risk update و Charter بعدی ساخته شود.
Report/Decision: داستان قابل‌دفاعی از آنچه فهمیده/نفهمیده‌ایم ارائه شود.

چه زمانی Charter مفید است؟

Requirement ناقص یا چندمعناست و باید رفتار واقعی را یاد گرفت.
تغییر جدید، بزرگ یا پرریسک است و Unknownها زیادند.
Incident تولید باید با مسیرهای مشابه و تغییر شرایط بررسی شود.
تست اسکریپتی سبز است، اما دربارهٔ Sequence، Interaction یا تجربه سؤال داریم.
محصول Legacy است و مدل/مستندات رفتاری کافی ندارد.
تیم می‌خواهد یک Persona، کیفیت یا Platform خاص را عمیق بررسی کند.
زمان محدود است و باید Mission اطلاعاتی اولویت‌دار تعریف شود.

چه زمانی Charter تنها ابزار کافی نیست؟

رأی Regression تکراری و دقیق می‌خواهید؛ Automated checks مناسب‌ترند.
Evidence الزام‌آور با Procedure تاییدشده لازم است؛ Charter می‌تواند مکمل باشد، نه جایگزین.
Performance، Security یا Conformance به Instrumentation/روش تخصصی نیاز دارد.
Oracle یا Test Basis آن‌قدر مبهم است که Session فقط اختلاف نظر تولید می‌کند؛ ابتدا Stakeholder alignment لازم است.
محیط ناامن یا دادهٔ حساس است و Safety boundary هنوز تعریف نشده است.

اولویت Charter را از Risk statement استخراج کنید. برای ساخت Condition→Event→Impact، Owner و Residual risk از راهنمای تست مبتنی بر ریسک کمک بگیرید.

قالب کوتاه Explore–With–To Discover

Explore [Target]
With [Resources / Data / Persona / Tactics]
To discover [Information / Risk / Question]

این قالب که در ادبیات عملی Chartering رایج شده، برای شروع عالی است. صفحهٔ ناشر کتاب Explore It! از Elisabeth Hendrickson نیز بخش مستقلی برای Chartering explorations دارد. اما برای کار تیمی/پرریسک، فقط یک جمله کافی نیست؛ Oracle، Safety، Identity و Evidence هم لازم‌اند.

مثال ضعیف و بهتر

ضعیف: «صفحهٔ پرداخت را کامل تست کن.» Target مبهم، «کامل» اثبات‌ناپذیر و اطلاعات موردنیاز نامعلوم است.

بهتر: «چرخهٔ پرداخت سفارش را با مبلغ‌های مرزی ریالی، رقم فارسی/لاتین و قطع اتصال هنگام بازگشت از PSP بررسی کن تا ناسازگاری مبلغ نمایشی/ثبت‌شده، وضعیت گیرکرده و مسیر بازیابی نامفهوم را کشف کنی.»

قالب کامل Charter Card

فیلد	راهنما
ID/Version	شناسه، نسخه و لینک Risk/Story/Incident
Mission	یک جملهٔ Explore–With–To Discover
Risk/Question	چرا این Session مهم است و کدام عدم‌قطعیت را کم می‌کند؟
Target/In scope	Feature، Interface، State، Persona یا Quality criterion هدف
Out of scope	مرز آگاهانه؛ نه ادعای بی‌اهمیت‌بودن
Sources/Models	Story، Contract، Log تولید، Design، SME یا مقایسهٔ نسخه
Data/Persona/Config	ورودی، حساب، Role، Locale، Platform، Clock و Dependency
Tactics/Heuristics	State/Sequence/Boundary/Interruption/Concurrency/Tours
Oracles	چگونه مشکل را تشخیص می‌دهیم و چه محدودیتی دارد؟
Safety/Constraints	PII، پرداخت، پیام واقعی، Rate limit، محیط و Stop condition
Timebox	بودجه و قواعد Branch/Extend/Stop
Evidence	چه Notes، Trace، ID، Screenshot، Dataset و نتیجه‌ای نگه داریم؟
Owner/Pair/Debrief	Tester، شریک، زمان و شرکت‌کنندگان Debrief

سیلابس ISTQB Advanced Test Analyst v4 نیز Mission، Scope/Objectives، محدودیت، زمان و ریسک را اجزای Charter می‌داند و تأکید می‌کند Charter خود Test Suite اجرایی را مشخص نمی‌کند.

مثال کامل: Charter پرداخت ایرانی

ID	PAY-EXP-07 / v1
Mission	چرخهٔ Order→Payment→Callback→Ledger را با Timeout پس از Commit، Callback تکراری/دیرهنگام و Retry کاربر بررسی کن تا ثبت مالی تکراری، ناسازگاری State و Recovery نامفهوم کشف شود.
Risk	کاربر دوبار بدهکار شود یا Order، Payment و Ledger دربارهٔ نتیجه اختلاف داشته باشند.
In scope	API Checkout، PSP virtual service، Callback، Order state، Ledger، Outbox و UI نتیجه
Out	Load ظرفیت PSP و تسویهٔ بانکی روز بعد؛ Charter جدا لازم دارد.
Data	۱۲۵٬۰۰۰ ریال، نمایش ۱۲٬۵۰۰ تومان، رقم فارسی/لاتین، callback_id یکتا/تکراری، Asia/Tehran + UTC
Tactics	State transition، Sequence permutation، timeout-before/after-commit، duplicate، refresh/back، concurrent retry
Oracles	حداکثر یک Ledger debit، یک Order final state، Event idempotency، مبلغ canonical ریال، پیام کاربر با مسیر پیگیری
Safety	فقط محیط غیرتولید؛ PSP واقعی/پیامک واقعی ممنوع؛ دادهٔ مصنوعی؛ Fault injection دارای Run ID
Timebox	۷۵ دقیقه + Debrief پانزده‌دقیقه‌ای؛ اگر اثر مالی کنترل‌نشده دیدیم Session متوقف و Incident ثبت شود.
Evidence	Build/Config، Run/Order/Attempt/Callback IDs، Timeline، درخواست/پاسخ، Snapshot دفترکل و Outbox، Notes و Bug/Question
Debrief	Tester + توسعه‌دهندهٔ Payment + Product؛ همان روز

چرا این Charter مفید است؟

Mission نوع Bug را دیکته نمی‌کند؛ ریسک و نقاط مشاهده را روشن می‌کند. تستر می‌تواند با دیدن Event دیرهنگام، مسیر جدیدی مثل Cancel هم‌زمان را دنبال کند، اما باید انحراف و دلیل را ثبت کند. Out-of-scope نیز نشان می‌دهد «بررسی‌نشده» با «بی‌خطر» یکی نیست.

Timebox را چگونه تعیین کنیم؟

Timebox ابزار تمرکز، ظرفیت و Debrief است؛ عدد مقدس نیست. Sessionهای کوتاه برای Survey یا Risk کوچک، و Sessionهای بلندتر برای Setup/Protocol/Device ممکن‌اند. Budget را با پیچیدگی Target، زمان Setup، عمق موردنیاز و توان تمرکز تعیین کنید.

قاعدهٔ Branch، Park، Extend و Stop

Branch: یافتهٔ خارج Mission با ریسک بالا و ارتباط مستقیم دارد؛ موقتاً دنبال کنید و دلیل را Note کنید.
Park: ایده مهم است ولی Mission را می‌بلعد؛ در Backlog Charter جدید قرار دهید.
Extend: با توافق Owner، سؤال اصلی نزدیک پاسخ است و هزینهٔ ادامه روشن است.
Stop: Safety breach، Build اشتباه، Environment نامعتبر، دادهٔ حساس یا مانع بنیادی داریم.

Session شکست‌خورده نیست اگر به‌دلیل مانع متوقف شود؛ «Environment نامعتبر و سؤال پاسخ‌نداده» یک نتیجهٔ معتبر است، به شرط اینکه پنهان نشود. چرخهٔ رسمی Test Run و Resultهای Pass/Fail/Blocked/Not Run در راهنمای مدیریت اجرای تست تکمیل شده است.

قبل از Session چه Preflightی لازم است؟

Build/Commit/Artifact و Feature flags درست‌اند.
Environment، Schema، Dependency و Clock معتبرند.
داده/Persona/Role آماده و Namespace/TTL مشخص است.
Risk/Story/Incident و منابع قابل دسترسی‌اند.
Tool، Proxy، Log/Trace و Capture کار می‌کنند.
Safety boundary، Secret/PII و اقدام ممنوع روشن است.
شرکت‌کنندهٔ Debrief و زمان آن مشخص است.
Charter به اندازهٔ Timebox کوچک و قابل‌فهم است.

اگر نیمی از Session صرف ساخت داده یا تعمیر محیط می‌شود، آن زمان را «Testing» جا نزنید؛ مانع و Setup را گزارش کنید. برای Data factory، Masking، Isolation و Retention به راهنمای TDM و برای Drift/Readiness به مدیریت محیط تست رجوع کنید.

در Session چگونه یادداشت برداریم؟

یادداشت باید فکر را پشتیبانی کند، نه تمرکز را نابود. از ساختار کم‌هزینه استفاده کنید:

14:10 ACTION       callback موفق را بعد از timeout تزریق کردم
14:11 OBSERVATION  Order=PAID، UI=UNKNOWN، Ledger rows=1
14:12 INFERENCE    شاید UI از read model عقب است؛ هنوز Defect قطعی نیست
14:13 QUESTION     SLA همگرایی read model چند ثانیه است؟
14:14 NEXT IDEA    refresh، login جدید، callback تکراری با همان ID
14:18 EVIDENCE     run=R42 order=O91 trace=T7 screenshot=S3

Observation را از تفسیر جدا کنید

Observation: آنچه واقعاً دیدید/اندازه گرفتید.
Inference: توضیح احتمالی شما.
Oracle/Reference: چرا شاید مشکل باشد.
Question: چه دانشی کم است.
Idea: آزمایش بعدی یا Charter بعدی.

این جداسازی از Bug report زودهنگام یا Assertion بی‌مدرک جلوگیری می‌کند. ارائهٔ An Exploratory Tester’s Notebook از Michael Bolton نمونه‌هایی از Notebook، Map و Session sheet را برای Accountable کردن کار اکتشافی نشان می‌دهد.

چه چیزهایی را ثبت کنیم؟

نوع	نمونه	خروجی
Bug/Anomaly	Callback تکراری Ledger دوم ساخته است.	Bug report + Evidence + Severity discussion
Question	SLA همگرایی وضعیت چیست؟	Owner و پاسخ/تصمیم
Risk	Retry کاربر با Callback دیرهنگام تداخل دارد.	Risk register/update
Coverage	Stateهای PAID/UNKNOWN دیده شد؛ REFUNDED نه.	Coverage map و Gap
Model	نقشهٔ State/Event و Dependency	مدل مشترک/Charter جدید
Test idea	Cancel هم‌زمان با Verify	Backlog اکتشافی یا Automated check
Obstacle	Log فاقد callback_id بود.	Testability/Observability task
Positive learning	Idempotency در Retry یکسان درست بود.	Evidence با محدوده و نسخه

Oracle در تست اکتشافی چگونه کار می‌کند؟

Oracle وسیله یا اصل تشخیص مشکل است؛ لزوماً Expected Result دقیق از پیش‌نوشته‌شده نیست. منابع Oracle می‌توانند Requirement، Contract، محصول قبلی، رفتار همساز، انتظار کاربر، قانون حسابداری، دادهٔ مستقل یا Subject Matter Expert باشند.

مدل FEW HICCUPPS از DevelopSense مجموعه‌ای Heuristic از Consistencyها برای تشخیص مشکل پیشنهاد می‌کند؛ خود منبع نیز آن را Exhaustive یا اثبات‌کننده نمی‌داند. در Charter بنویسید کدام Oracleها محتمل‌اند و محدودیتشان چیست.

Oracle پرداخت

Consistency با Contract PSP و API؛
Consistency داخلی Order/Payment/Ledger/Outbox؛
Invariant مالی: حداکثر یک Debit برای Attempt؛
Expectation کاربر: نتیجهٔ نامشخص باید مسیر پیگیری بدهد؛
History: نسخهٔ پیشین چگونه رفتار می‌کرد، بدون فرض اینکه قبلی حتماً درست بوده؛
Law/Policy: فقط با تفسیر صاحب صلاحیت، نه حدس تستر.

Heuristic و Tactic را چگونه انتخاب کنیم؟

Heuristic یادآور و محرک فکر است، نه چک‌لیست پوشش کامل. بر اساس Risk چند زاویه انتخاب کنید:

State/Sequence: ترتیب، بازگشت، تکرار، لغو، Retry و Resume؛
Data: صفر، مرز، بزرگ، Null، Unicode، تکراری و ناسازگار؛
Interaction: چند Actor، Tab، Device، Session و Role؛
Platform: Browser، OS، Network، Locale، Timezone و Device؛
Failure: Timeout، partial commit، outage، malformed response و capacity؛
Quality: Security، usability، accessibility، reliability و recoverability؛
History: Incident، تغییر اخیر، defect cluster و workaround؛

صفحهٔ منابع تست DevelopSense، HTSM را ابزاری برای توسعه، سازمان‌دهی و توجیه استراتژی تست معرفی می‌کند و یادآور می‌شود که خود مدل و استراتژی هر دو Heuristic و خطاپذیرند. چند Heuristic مرتبط انتخاب کنید؛ ریختن همهٔ Acronymها در Charter تمرکز را از بین می‌برد.

پوشش تست اکتشافی را چگونه گزارش کنیم؟

«۸۰٪ پوشش اکتشافی» بدون مدل و مخرج بی‌معناست. Coverage را به‌صورت Map و Story گزارش کنید:

بعد	نمونهٔ پوشیده‌شده	Gap/Limit
State	CREATED، PENDING، PAID، UNKNOWN	CANCELLED/REFUNDED بررسی نشد
Sequence	Timeout→Callback→Retry	Cancel هم‌زمان پارک شد
Data	ریال، تومان نمایشی، رقم فارسی/لاتین	سقف مبلغ PSP بررسی نشد
Interface	UI، Checkout API، Callback، Ledger	تسویهٔ روز بعد خارج Scope
Platform	Chrome/Android، شبکه قطع/وصل	iOS و WebView بررسی نشد
Quality/Risk	Consistency، Idempotency، Recovery	Performance/Accessibility Charter جدا

Coverage note نمی‌گوید محصول درست است؛ می‌گوید کجا با چه زاویه‌ای بررسی شده و کجا Unknown مانده است. پژوهش باز Checklists to Support Test Charter Design نیز مجموعه‌ای از عوامل و عناصر محتوا را از مصاحبه‌ها استخراج کرده است؛ Checklist را برای Reflection به کار ببرید، نه اثبات Exhaustiveness.

Debrief؛ مهم‌ترین بخش فراموش‌شده

Debrief دفاع از Tester یا شمارش Bug نیست؛ گفت‌وگویی برای تبدیل تجربهٔ Session به اطلاعات و اقدام مشترک است. نوشتهٔ Michael Bolton دربارهٔ Debrief Session پرسش‌ها را حول Charter، محصول، Testing، Coverage، Problems و کار باقی‌مانده می‌چیند.

پروتکل Debrief پانزده‌دقیقه‌ای

Charter versus reality: Mission انجام شد؟ کجا و چرا منحرف شدیم؟
Product story: چه یاد گرفتیم؛ محصول چگونه عمل کرد؛ کدام مشکل/سؤال مهم است؟
Testing story: چه مدل، داده، Tactic و Oracleی استفاده شد؟
Coverage story: چه ابعادی دیده شد و چه Gapهایی باقی است؟
Obstacle: محیط، داده، Testability یا دانش چه مانعی ساخت؟
Decision: Bug/Question/Risk/Automation/Charter بعدی و Owner چیست؟

برای Charter پرریسک یا Tester تازه، Debrief می‌تواند طولانی‌تر و Coachingمحور باشد. برای Mission کوچک و تیم هم‌فهم، ممکن است کوتاه باشد. کیفیت گفت‌وگو مهم‌تر از مدت ثابت است.

چگونه یافته را قابل‌بازتولید کنیم؟

کل فرایند فکری Session را نمی‌توان و نباید دقیق Replay کرد؛ اما یافته‌ای که قرار است تصمیم یا Fix بسازد باید Evidence بازتولیدپذیر داشته باشد:

Build/Commit/Config/Environment؛
Data و Precondition با Masking لازم؛
حداقل Sequence محرک؛
Expected/Oracle و Actual observation؛
Run/Request/Order/Trace IDs و Timestamp؛
Side effectها و Stateهای مرتبط؛
Frequency و Variations امتحان‌شده؛
Screenshot/Video/Log فقط به‌عنوان مکمل، نه جای توضیح.

Bug report را می‌توان در Review هم به چالش کشید: آیا مشکل واقعاً مشاهده شد، Oracle معتبر است و مسیر حداقل شده؟ الگوی Peer Review شواهد در راهنمای بازبینی تست‌کیس و کد تست آمده است.

Portfolio منشورها را چگونه مدیریت کنیم؟

Charterها را از لیست Feature نسازید؛ از Risk، تغییر و Unknown بسازید. یک Matrix ساده نگه دارید:

Risk/Question	Priority	Charter	Status	Evidence/Finding	Next
Duplicate callback	High	PAY-EXP-07	Debriefed	Bug B-441 + trace	Fix + confirmation + invariant check
Refund/Cancel race	High	PAY-EXP-08	Ready	—	Pair with backend dev
Persian digit parsing	Medium	PAY-EXP-09	Parked	Question Q-19	Product rule
PSP max amount	Medium	PAY-EXP-10	Blocked	Sandbox limit unknown	Owner: Integration lead

Status را با Evidence و Decision پیوند دهید. «Session انجام شد» به‌تنهایی ارزش یا کفایت نمی‌گوید.

Charter در Sprint و CI/CD

Refinement: Unknownها و Exampleهای مبهم را به Learning charter تبدیل کنید.
Development: Pair exploration روی Build محلی/Review app با Developer.
Pre-merge: Charter کوچک برای تغییر پرریسک؛ Result جای Checkهای deterministic را نگیرد.
Release: Risk-targeted Session روی Artifact نامزد و Environment معلوم.
Post-deploy: Observation امن و غیرمخرب با Scope/Guardrail تولید.
Incident: Charter از Timeline و Failure mechanism Incident ساخته شود.

خروجی Session باید وارد جریان کار شود: Bug، Clarification، Testability، automated check، Risk memo یا No-action با دلیل. گزارش حرفه‌ای Status/Gap/Residual risk و تصمیم انتشار در راهنمای گزارش تست توضیح داده شده است.

Pair و Mob Exploratory Testing

Pair کردن Tester با Developer، Product، Designer، Security یا Support مدل‌ها و Oracleهای متفاوت را کنار هم می‌آورد. نقش‌ها را شفاف کنید:

Driver: تعامل/ابزار را هدایت می‌کند.
Navigator: مدل، سؤال، Coverage و Note را دنبال می‌کند.
Domain voice: Contract و پیامد را توضیح می‌دهد، نه اینکه هر Observation را فوراً رد کند.
Observer: Bias، مانع یا Timeline را ثبت می‌کند.

نقش‌ها را در Session جابه‌جا کنید. Pair نباید به نمایش کار Tester برای Manager تبدیل شود؛ باید ظرفیت مشاهده و یادگیری را افزایش دهد.

Metrics سالم و ناسالم

Metrics سالم

Charterهای High-risk دارای Evidence تازه / کل Charterهای High-risk؛
زمان از Session تا Debrief/Decision؛
درصد Sessionهای Blocked و علت Data/Environment/Access/Knowledge؛
Follow-upهای بی‌مالک یا منقضی؛
Question resolution time؛
Coverage gapهای پرریسک و سن آن‌ها؛
نرخ Bugهای Duplicate/Not reproducible با علت؛
Session time versus Setup/Bug investigation با تفسیر زمینه‌ای؛
Incidentهایی که Model/Charter جدید ساخته‌اند؛
Automation/Testability improvements حاصل از Session.

Metrics ناسالم

Bug per tester/session به‌عنوان Productivity؛
Charter completion count بدون Risk/Outcome؛
درصد Coverage بدون مدل و مخرج؛
ساعت تست به‌عنوان ارزش؛
نرخ Pass/Fail برای Session اکتشافی بدون Story یافته‌ها؛

Session با صفر Bug می‌تواند مدل مهمی را تایید، Risk را محدود یا Testability gap را کشف کند. در مقابل، ده Bug ظاهری Duplicate یا کم‌اثر ممکن است اطلاعات کمی بدهد. راهنمای متریک‌های تست برای تعریف سؤال، مخرج و تصمیم قابل‌استفاده است.

امنیت، حریم خصوصی و ایمنی Session

Environment و Actionهای مجاز/ممنوع را در Charter بنویسید.
دادهٔ شخصی، Token، شماره کارت/موبایل و Trace را Minimize/Mask کنید.
Fault injection، Load، پیامک/ایمیل و پرداخت واقعی نیاز به مجوز دارد.
Screenshot/Video می‌تواند PII و Secret ثبت کند؛ Retention و Access لازم است.
Cleanup باید Scopeدار و قابل‌اثبات باشد؛ دادهٔ مشترک را حذف نکنید.
در تولید از Guardrail، Canary account، Rate limit و Stop condition استفاده کنید.

خطاهای رایج در نوشتن و اجرای Charter

Mission کلی: «Feature را کامل تست کن.»
Test Case پنهان: Charter به ۳۰ گام اجباری تبدیل می‌شود.
Bug-only success: یادگیری، سؤال و Coverage بی‌ارزش شمرده می‌شوند.
Scope بدون Risk: صفحه/Feature هدف است، اما چرایی معلوم نیست.
بدون Oracle: Tester رفتار عجیب می‌بیند ولی نمی‌تواند Problem را Frame کند.
Heuristic dumping: همهٔ Mnemonicها بدون ارتباط با Mission اضافه می‌شوند.
Timebox مقدس: Session با Safety breach ادامه یا با سؤال نزدیک پاسخ ناگهان قطع می‌شود.
بدون Notes: تنها حافظه یا Screenshot خام باقی می‌ماند.
بدون Debrief: یافته‌ها به Backlog/Decision وصل نمی‌شوند.
Coverage درصدی ساختگی: بدون مدل عدد گزارش می‌شود.
داده/محیط مشترک: Observation به Run دیگری آلوده است.
Branch بی‌پایان: هر موضوع جالب Mission را می‌بلعد.
Charter factory: Manager ده‌ها Charter می‌نویسد و Tester فقط اجرا می‌کند.
Session بدون امنیت: تست در تولید پیام/پرداخت/دادهٔ واقعی می‌سازد.
KPI فردی: Bug/hour یا Session count رفتار را منحرف می‌کند.

برنامهٔ ۳۰روزهٔ استقرار Charter و SBTM

هفتهٔ اول: زبان و Pilot

Charter، Session، Note، Evidence و Debrief را برای تیم تعریف کنید.
سه Risk واقعی و کوچک انتخاب کنید.
قالب Charter Card و Note کم‌هزینه را Pilot کنید.

هفتهٔ دوم: Debrief و Coaching

Sessionها را Pair و همان روز Debrief کنید.
Missionهای خیلی کلی/اسکریپتی را با مثال اصلاح کنید.
Observation/Inference/Question و Oracle framing را تمرین کنید.

هفتهٔ سوم: Portfolio و جریان کار

Risk→Charter→Evidence→Finding→Next را در Board اضافه کنید.
Bug/Question/Automation/Testability خروجی را Ownerدار کنید.
Blocked/Setup و Coverage gap را قابل‌مشاهده کنید.

هفتهٔ چهارم: Governance سبک

Safety/PII/Production guardrail و Retention را تصویب کنید.
Metrics ناسالم را حذف و دو یا سه Metric تصمیم‌ساز انتخاب کنید.
Charterهای انجام‌شده را نمونه‌برداری و Debrief quality را Coaching کنید.
فرایند را با Feedback Tester/Developer/Product ساده‌تر کنید.

برای دیدن الگوها و صورت‌بندی‌های متفاوت، راهنمای نوشتن Exploratory Charter کنست نقطهٔ شروع عملی دیگری است. فرایند باید یادگیری و انتخاب تستر را قابل‌مشاهده و قابل‌گفت‌وگو کند، نه اینکه با Template سنگین جایگزینش کند.

چک‌لیست کیفیت Charter

Mission در یک یا دو جمله قابل توضیح است.
Risk/Question و Stakeholder آن معلوم است.
Target/In/Out به اندازهٔ Timebox محدود است.
Source/Model و Unknownهای مهم لینک شده‌اند.
Data/Persona/Role/Platform/Clock/Dependency مشخص‌اند.
Tacticها مرتبط‌اند، نه فهرست همهٔ تکنیک‌ها.
Oracleها و محدودیت هرکدام نوشته شده‌اند.
Safety، PII، محیط و Stop condition روشن‌اند.
Evidence مورد انتظار و Correlation IDs تعریف شده‌اند.
Branch/Park/Extend policy وجود دارد.
Tester اختیار تغییر مسیر با ثبت دلیل دارد.
Debrief و افراد لازم از قبل مشخص‌اند.
خروجی به Bug/Question/Risk/Test idea/Charter بعدی وصل می‌شود.
Coverage به شکل مدل و Gap گزارش می‌شود، نه درصد بی‌مخرج.

پرسش‌های متداول دربارهٔ منشور تست اکتشافی

Charter باید چقدر کوتاه باشد؟

Mission بهتر است در یک یا دو جمله جا شود، اما Charter Card برای ریسک جدی می‌تواند داده، Oracle، Safety و Evidence بیشتری داشته باشد. معیار، قابلیت فهم و اجرا در Timebox است؛ نه تعداد کلمه. اگر ۳۰ گام اجباری دارد احتمالاً Test Procedure نوشته‌اید.

آیا هر Session باید بدون وقفه و دقیقاً ۶۰ تا ۱۲۰ دقیقه باشد؟

نه. SBTM کلاسیک Session متمرکز و Timeboxدار را پیشنهاد می‌کند، اما Context تعیین‌کننده است. Mission کوچک ممکن است ۳۰ دقیقه و بررسی Device/Protocol طولانی‌تر باشد. وقفه را ثبت کنید؛ اگر محیط کار دائماً قطع می‌شود، Thread-based یا Sessionهای کوچک‌تر شاید صادقانه‌تر باشند.

چه کسی Charter را می‌نویسد؟

Tester، Developer، Product، Support یا گروه می‌توانند پیشنهاد دهند؛ اما Tester اجراکننده باید Mission را بفهمد و در مذاکرهٔ آن نقش داشته باشد. Charter تحمیلی که مسیر را از قبل دیکته کند، مهارت اکتشافی را کاهش می‌دهد.

چگونه ثابت کنیم تست اکتشافی انجام شده است؟

با داستان قابل‌دفاع: Charter/Version، Build و Environment، Timebox، Notes، Coverage map، داده/Tactic/Oracle، Evidence یافته‌ها، موانع، Gap و Debrief decisions. هدف ثبت هر Click نیست؛ امکان توضیح کار، یافته و محدودیت است.

اگر Session هیچ باگی پیدا نکرد، بی‌فایده بوده است؟

خیر. ممکن است سؤال را پاسخ داده، مدل محصول را بهتر کرده، Risk را محدود، Coverage gap یا Testability obstacle را آشکار و ایدهٔ Automation ساخته باشد. بااین‌حال «هیچ Bugی ندیدیم» نیز اثبات نبود Bug نیست؛ Scope، Oracle و محدودیت Evidence باید گزارش شود.

جمع‌بندی

منشور خوب آزادی و Accountability را هم‌زمان حفظ می‌کند. نه Test Case پنهان است و نه مجوز پرسه‌زدن بی‌هدف. زنجیرهٔ ارزش آن چنین است: Risk/Question → Mission → Target/Tactics/Oracle/Safety → Session و Notes → Evidence/Coverage → Debrief → Decision و Charter بعدی.

از یک Charter کوچک روی یک Risk واقعی شروع کنید. Observation را از Inference جدا، Out-of-scope را صریح، Timebox را قابل‌مذاکره و Debrief را اجباری کنید. موفقیت را با Bug/hour نسنجید؛ ببینید Session چه عدم‌قطعیتی را برای کدام تصمیم کم کرده و کدام Unknown را صادقانه باقی گذاشته است.

تست نرم افزار, سطوح تست

منشور تست اکتشافی؛ از Charter تا Debrief