تست اکتشافی چیست؟ آموزش Session، Charter و گزارش

تست‌های Checkout سبزند، اما شما یک سؤال ساده می‌پرسید: «اگر کاربر بعد از پرداخت، صفحه را Refresh کند چه می‌شود؟» همین سؤال ممکن است سفارشی تکراری، کسر موجودی اشتباه یا پیام متناقض را آشکار کند. این ارزش تست اکتشافی است: طراحی و اجرای تست با یادگیری لحظه‌به‌لحظه از رفتار واقعی محصول.

Exploratory Testing کلیک‌کردن بی‌برنامه نیست. با یک مأموریت روشن، مدل پوشش، یادداشت قابل‌ردیابی و Debrief کوتاه می‌توان آزادی فکر را با پاسخ‌گویی حرفه‌ای ترکیب کرد. در این راهنما، یک Session واقعی برای کد تخفیف و پرداخت فروشگاه طراحی می‌کنیم؛ Charter می‌نویسیم، از Oracle و Heuristic کمک می‌گیریم و گزارش قابل‌استفاده برای تیم می‌سازیم.

خلاصه عملی: هدف را در یک Charter بنویسید، زمان را محدود کنید، حین کار «تست، یادگیری و طراحی تست بعدی» را ثبت کنید، شواهد را امن نگه دارید و در Debrief درباره پوشش، یافته، مانع و مأموریت بعدی تصمیم بگیرید.

تست اکتشافی چیست؟

تست اکتشافی رویکردی است که در آن یادگیری محصول، طراحی تست، اجرای تست و ارزیابی نتیجه به‌صورت یک جریان درهم‌تنیده پیش می‌روند. تستر بر اساس مشاهده جدید، مدل ذهنی خود و تست بعدی را اصلاح می‌کند. این تعریف با سرفصل ISTQB CTFL v4.0.1 هم‌راستاست.

«اکتشافی» و «اسکریپتی» دو جعبه کاملاً جدا نیستند؛ میزان ازپیش‌طراحی‌شدن روی یک طیف قرار دارد. یک Session ممکن است Charter آزاد داشته باشد اما از جدول تصمیم آماده، داده مشخص و Script ثبت رویداد استفاده کند. یک Test Case نیز ممکن است هنگام اجرا سؤال‌های اکتشافی ایجاد کند.

چهار فعالیت هم‌زمان

• یادگیری: محصول، کاربر، معماری، داده و ریسک را بهتر می‌شناسید.
• طراحی: تست بعدی را بر اساس مدل و یافته فعلی انتخاب می‌کنید.
• اجرا: داده و عملیات را روی محصول یا Component اعمال می‌کنید.
• ارزیابی: نتیجه را با Oracle مقایسه و اهمیت آن را بررسی می‌کنید.

تفاوت تست اکتشافی با Ad-hoc و تست اسکریپتی

رویکرد	هدایت تست	یادگیری حین اجرا	شواهد معمول	کاربرد مناسب
اسکریپتی	مراحل و نتیجه موردانتظار از پیش نوشته شده	ممکن است، اما محور اصلی نیست	Result هر Test Case	Regression تکرارشونده، انطباق و رفتار شناخته‌شده
اکتشافی	مأموریت، ریسک و مدل؛ مسیر با یافته تغییر می‌کند	هسته فعالیت	یادداشت، Coverage، Bug، Question و Artifact	ابهام، تغییر جدید، ریسک ناشناخته و بازخورد سریع
Ad-hoc	ساختار و سابقه محدود	ممکن است وجود داشته باشد	معمولاً کم یا نامنسجم	بررسی سریع محدود؛ برای ادعای پوشش کافی نیست

Ad-hoc الزاماً «تصادفی و بی‌هدف» نیست، اما معمولاً مأموریت، مدل پوشش و ثبت منظم کمتری دارد. تفاوت حرفه‌ای تست اکتشافی در فکر آگاهانه و قابلیت توضیح تصمیم‌هاست، نه صرفاً نداشتن Step.

تست اکتشافی جایگزین همه Test Caseها نیست. رفتارهای پایدار و پرتکرار می‌توانند در Test Caseهای قابل‌تکرار یا اتوماسیون قرار گیرند؛ زمان انسان را برای یادگیری و خطرهای جدید آزاد کنید.

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

• نیازمندی مبهم است یا مثال کافی ندارد؛
• Feature تازه یا به‌شدت تغییرکرده است؛
• زمان محدود است و باید سریع تصویر ریسک بسازید؛
• Incident رخ داده و مسیر شکست کامل روشن نیست؛
• تست‌های خودکار سبزند، اما اعتماد محصولی کافی وجود ندارد؛
• تعامل چند Component، نقش کاربری یا حالت پیچیده است؛
• قابلیت استفاده، پیام خطا و رفتار واقعی کاربر مهم است؛
• می‌خواهید پیش از Regression رسمی، Smoke عمیق‌تری انجام دهید.

برای یک محاسبه مالی ثابت یا کنترل انطباق رسمی، تست دقیق و تکرارپذیر نیز لازم است. رویکرد را بر اساس ریسک انتخاب کنید، نه سلیقه تیم.

تست اکتشافی مبتنی بر Session یا SBTM چیست؟

Session-Based Test Management راهی برای مدیریت تست اکتشافی با مأموریت، Timebox، یادداشت و Debrief است. این روش را James Bach و Jonathan Bach معرفی کردند؛ مقاله اصلی Session-Based Test Management تاریخچه و عناصر آن را توضیح می‌دهد.

Timebox قانون جهانی ۶۰ یا ۹۰ دقیقه ندارد. مدت را بر اساس پیچیدگی و توان تمرکز انتخاب کنید؛ برای شروع، ۴۵ تا ۶۰ دقیقه کار متمرکز به‌علاوه آماده‌سازی و Debrief کوتاه عملی است. اگر Incident، خطر امنیتی یا خرابی داده دیدید، شرط توقف بر Timebox مقدم است.

چرخه یک Session

1. آماده‌سازی: مأموریت، دامنه، محیط، داده، Oracle و شرط توقف؛
2. کاوش: تست و یادگیری همراه با یادداشت زمان‌دار؛
3. بررسی شواهد: بازتولید کنترل‌شده و پاک‌سازی Artifact؛
4. Debrief: پوشش، یافته، سؤال، مانع و اقدام بعدی؛
5. به‌روزرسانی نقشه: ریسک و Charterهای بعدی.

چگونه Test Charter بنویسیم؟

Charter دستورالعمل قدم‌به‌قدم نیست؛ قطب‌نمای Session است. یک الگوی ساده:

کاوشِ [هدف] با استفاده از [منابع/روش‌ها] برای کشف اطلاعات درباره [ریسک یا کیفیت]

نمونه ضعیف و نمونه بهتر

ضعیف: «سبد خرید را تست کن.»

بهتر: «اعمال و حذف کد تخفیف را برای سبدهای چندکالایی، کاربران مهمان و عضو، با داده مرزی و تغییر هم‌زمان قیمت کاوش کن تا ریسک محاسبه نادرست مبلغ و نمایش پیام متناقض آشکار شود.»

اجزای پیشنهادی Charter

• Mission: چه اطلاعاتی می‌خواهیم؟
• Scope: چه Feature، API، Role و پلتفرمی داخل یا خارج دامنه است؟
• Risks: چه شکستی برای مشتری یا کسب‌وکار مهم است؟
• Data/Tools: حساب، داده، Proxy، Log یا DevTools موردنیاز؛
• Oracle: درست یا نادرست را با چه مرجعی تشخیص می‌دهیم؟
• Stop conditions: خرابی داده، اثر مالی واقعی، دسترسی غیرمجاز یا پایان Timebox.

آموزش عملی: یک Session اکتشافی برای تخفیف و پرداخت

زمینه و ریسک

یک فروشگاه ایرانی امکان اعمال کد تخفیف قبل از انتقال به درگاه دارد. Feature تازه تغییر کرده و ریسک‌های اصلی عبارت‌اند از مبلغ اشتباه، استفاده بیش از حد، اختلاف مبلغ Order و Payment و رفتار نادرست پس از انقضا.

Charter

اعمال کد تخفیف را در سبد و Checkout با داده‌های مرزی، تغییر زمان و عملیات تکراری کاوش کن تا ناسازگاری مبلغ، دورزدن محدودیت مصرف و انتقال حالت نادرست سفارش کشف شود. پرداخت واقعی، تست بار و دسترسی به داده کاربران خارج از دامنه است.

آماده‌سازی ۱۰دقیقه‌ای

• Build و محیط Staging ثبت شود؛
• دو حساب مصنوعی و چند کالای تست آماده باشد؛
• قانون تخفیف از Product owner تأیید شود؛
• DevTools و Log مجاز باز باشد؛
• ساعت Server و Client معلوم باشد؛
• هیچ کارت، شماره تلفن یا نشانی واقعی استفاده نشود.

مدل پوشش اولیه

بُعد	نمونه کلاس‌ها
کاربر	مهمان، عضو عادی، کاربر قبلاً استفاده‌کرده
کد	معتبر، نامعتبر، منقضی، هنوز فعال‌نشده، حروف کوچک/بزرگ، فاصله
سبد	خالی، حداقل مبلغ −۱/برابر/+۱، کالای مجاز و غیرمجاز، چند فروشنده
عملیات	Apply، Remove، Apply تکراری، Back، Refresh، دو Tab
حالت	Cart، Checkout، Payment pending، Paid، Cancelled
اختلال	Timeout، پاسخ تکراری، قطع شبکه، تغییر قیمت

برای قواعد ترکیبی از جدول تصمیم و برای وضعیت Order/Payment از مدل انتقال حالت کمک بگیرید. تکنیک‌های رسمی، آزادی کاوش را محدود نمی‌کنند؛ ایده‌های دقیق‌تری می‌سازند.

یادداشت زنده Session

زمان	عمل/داده	مشاهده	ایده یا شواهد
10:05	مبلغ دقیق حداقل؛ کد معتبر	تخفیف اعمال شد	Request A12، مبلغ قبل/بعد ثبت شد
10:12	افزایش تعداد کالا در Tab دوم	Tab اول مبلغ قدیمی نشان داد	آیا Server هنگام پرداخت دوباره محاسبه می‌کند؟
10:21	Apply دوباره پس از Refresh	دو پیام موفقیت؛ مبلغ یک‌بار کم شد	مشکل UX یا Idempotency؟ Video E03
10:33	انقضا بین Cart و Checkout	UI تخفیف را حفظ کرد؛ API رد کرد	اختلاف State؛ Bug candidate B07
10:44	Timeout پاسخ Apply	دکمه فعال و سه Request ایجاد شد	ریسک Race؛ نیاز به Log correlation

این یادداشت جای Bug Report نهایی نیست. ابتدا مشاهده را از فرضیه جدا کنید، سپس مورد مهم را در محیط مجاز بازتولید و طبق الگوی گزارش باگ ثبت کنید.

Debrief ده‌دقیقه‌ای

• مأموریت: آیا روی ریسک تخفیف و مبلغ ماندیم؟
• پوشش: چه Role، State، Data و Platform دیده یا دیده نشد؟
• یافته: Bug، Risk، Question و Test idea چه بود؟
• مانع: Log ناقص، داده نامعتبر یا اختلال محیط داشتیم؟
• اقدام: چه کسی Bug را Triage می‌کند و Charter بعدی چیست؟

خروجی این مثال می‌تواند یک Bug درباره انقضای بین Cart و Checkout، یک سؤال درباره منبع حقیقت مبلغ و Charter بعدی برای callback تکراری پرداخت باشد. «پنج باگ پیدا شد» به‌تنهایی گزارش ارزشمندی نیست.

Oracle؛ از کجا بفهمیم رفتار درست است؟

Oracle منبع یا اصلی است که برای ارزیابی نتیجه استفاده می‌کنیم. هیچ Oracle همیشه کامل نیست؛ گاهی اختلاف بین دو منبع خود یک یافته است.

• قواعد محصول: Acceptance Criteria، قرارداد، سیاست تخفیف و نمونه تأییدشده؛
• سازگاری داخلی: UI، API، پایگاه داده و گزارش مالی باید روایت سازگاری داشته باشند؛
• تاریخچه: رفتار نسخه پایدار قبلی، با احتیاط نسبت به باگ قدیمی؛
• انتظار کاربر: الگوهای پلتفرم، دسترس‌پذیری و زبان روشن؛
• استاندارد یا قانون: فقط وقتی دامنه و نسخه الزام روشن است؛
• Log و Telemetry: برای فهم رفتار، نه اثبات خودکار درستی کسب‌وکار.

اگر Oracle مبهم است، «سؤال محصول» ثبت کنید؛ هر مشاهده متفاوت الزاماً Defect نیست.

هیوریستیک‌ها برای تولید ایده تست

Heuristic قانون تضمینی نیست؛ یادآوری برای دیدن زاویه‌های بیشتر است. آن را به Checklist کور تبدیل نکنید.

SFDIPOT؛ نقشه محصول

• Structure: اجزا، فایل‌ها، سرویس‌ها و وابستگی‌ها؛
• Function: قابلیت‌ها، محاسبات و خطاها؛
• Data: ایجاد، خواندن، تغییر، حذف، قالب و عمر داده؛
• Interfaces: API، UI، Queue، درگاه و سرویس بیرونی؛
• Platform: مرورگر، سیستم‌عامل، Device، شبکه و Locale؛
• Operations: کاربر، پشتیبانی، Deploy، Backup و مانیتورینگ؛
• Time: Timeout، انقضا، ترتیب، هم‌زمانی و منطقه زمانی.

CRUD و چرخه عمر داده

Create/Read/Update/Delete شروع خوبی است، اما Archive، Restore، Import/Export، Duplicate، Audit و Retention را نیز بسته به محصول بررسی کنید.

مرز، ترکیب و حالت

حداقل و حداکثر، درست قبل/بعد مرز، ترکیب قواعد و Transitionهای نامعتبر بیشترین سؤال را تولید می‌کنند. به‌جای تکرار مکانیکی، از مدل محصول برای انتخاب استفاده کنید.

Software Tour؛ لنز کاوش، نه مدرک پوشش

• Money Tour: جریان درآمد، پرداخت، اشتراک، تخفیف و بازپرداخت؛
• Data Tour: داده از ورود تا ذخیره، نمایش، Export و حذف؛
• Claims Tour: هر ادعای صفحه، راهنما، تبلیغ یا قرارداد را بررسی کنید؛
• Interruption Tour: قطع شبکه، Back، Refresh، Session expiry و Retry؛
• Configuration Tour: Role، Feature flag، Locale و تنظیمات مختلف؛
• History Tour: ناحیه‌های پرحادثه و تغییرهای اخیر.

تور یک موتور ایده است. نوشتن «Money Tour انجام شد» ثابت نمی‌کند همه ریسک‌های مالی پوشش یافته‌اند؛ ناحیه، داده، حالت و محدودیت واقعی را ثبت کنید.

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

پوشش اکتشافی را نمی‌توان با درصد ظاهراً دقیق از «همه چیز» بیان کرد، مگر اینکه مخرج مشخص باشد. چند مدل کوچک بسازید:

• نقشه Feature و زیرناحیه؛
• Role و Permission؛
• State و Transition؛
• کلاس داده و مرز؛
• Platform، Locale و شبکه؛
• Risk و Quality characteristic؛
• تغییرهای اخیر و وابستگی‌ها.

در Session report مشخص کنید کدام خانه‌ها عمیق، سطحی، مسدود یا خارج دامنه بوده‌اند. Heatmap کیفی با توضیح تعریف، از درصد پوششی که مخرج ندارد صادقانه‌تر است.

چه چیزهایی را اندازه نگیریم؟

• تعداد باگ به‌ازای Tester یا Session به‌عنوان هدف؛
• درصد «پایبندی به Charter» به شکلی که انحراف مفید را تنبیه کند؛
• تعداد Click، Screenshot یا Test idea به‌عنوان بهره‌وری؛
• مقایسه Sessionهای دو Feature با پیچیدگی متفاوت.

بهتر است زمان صرف‌شده، دامنه و ریسک پوشش‌داده‌شده، موانع، یافته‌های قابل‌اقدام و سؤال‌های باز را برای برنامه‌ریزی ببینید. اصول ضدبازی در راهنمای متریک‌های تست توضیح داده شده است.

ثبت شواهد بدون از دست‌دادن جریان فکر

• یادداشت کوتاه زمان‌دار با شناسه داده و Build؛
• Screenshot یا Video فقط هنگام ارزش تشخیصی؛
• HAR و Log با حذف Token، Cookie و اطلاعات شخصی؛
• شناسه Request/Correlation برای اتصال UI و Backend؛
• علامت‌های جدا برای Bug، Question، Risk و Test idea؛
• بازسازی مراحل مهم بلافاصله پس از Session.

در محصولات ایرانی، شماره موبایل، کد ملی، نشانی، اطلاعات بانکی و داده پشتیبانی را در Video یا Ticket عمومی قرار ندهید. حساب مصنوعی و داده Masked استفاده کنید و سیاست نگهداری Artifact داشته باشید.

Pair و Mob Exploratory Testing

در Pair testing دو نفر با نگاه‌های مکمل—مثلاً QA و Developer یا QA و Product—یک مأموریت را کاوش می‌کنند. یک نفر تعامل و یادداشت را هدایت می‌کند و دیگری مدل، Log و ایده‌ها را به چالش می‌کشد؛ نقش‌ها را دوره‌ای عوض کنید.

این روش برای Feature پیچیده، انتقال دانش دامنه و Triage سریع مفید است. با این حال، دو نفره بودن جای Charter و ثبت شواهد را نمی‌گیرد و برای همه Sessionها از نظر هزینه لازم نیست.

جای تست اکتشافی در Agile و CI/CD

• Refinement: مثال‌ها، ابهام و Riskها را پیش از توسعه کاوش کنید.
• حین توسعه: روی Prototype، API یا Build کوچک بازخورد زودهنگام بدهید.
• پس از CI: از نتیجه تست خودکار برای انتخاب ناحیه اکتشاف استفاده کنید.
• پیش از Release: Charterهای ریسک باقی‌مانده و تغییرهای اخیر را اجرا کنید.
• پس از Incident: مدل شکست را بسازید و Regression/Charter تازه استخراج کنید.

در تیم چابک، تست اکتشافی مرحله‌ای در انتهای Sprint نیست؛ یکی از حلقه‌های بازخورد است. همکاری آن با سایر فعالیت‌ها در راهنمای تست چابک آمده است.

از یافته اکتشافی تا Regression پایدار

1. یافته را بازتولید و علت یا شرط لازم را تا حد کافی روشن کنید.
2. ریسک و احتمال تکرار را ارزیابی کنید.
3. اگر رفتار پایدار و ارزشمند است، مناسب‌ترین لایه تست را انتخاب کنید.
4. تست کوچک و قابل‌اعتماد بسازید؛ همه مسیر Session را عیناً خودکار نکنید.
5. Charter و مدل پوشش را با دانشی که به دست آمده به‌روز کنید.

هنگام اجرای تست، نتیجه اکتشافی را از اجرای Test Case جدا اما به Requirement، Build و Risk مرتبط نگه دارید تا گزارش انتشار قابل‌ردیابی بماند.

الگوی گزارش Session قابل کپی

Session ID:
تاریخ / تستر / مدت:
Build / محیط:
Charter:
داخل دامنه / خارج دامنه:
مدل‌ها و داده‌های استفاده‌شده:

پوشش:
- عمیق:
- سطحی:
- مسدود:
- تست‌نشده:

یافته‌ها:
- Bug:
- Risk:
- Question:
- Test idea:

موانع و زمان وقفه:
Artifactهای امن:
ریسک باقی‌مانده:
Charter یا اقدام بعدی:

این الگو را سبک نگه دارید. هدف، بازسازی تمام Clickها نیست؛ باید روایت تصمیم‌ها و شواهد مهم برای تیم قابل‌فهم باشد.

اشتباه‌های رایج

• «برو هرچه می‌توانی تست کن»: بدون مأموریت، اولویت و توقف، انرژی پراکنده می‌شود.
• نوشتن Charter شبیه Test Case: آزادی یادگیری از بین می‌رود.
• شمردن باگ به‌عنوان بهره‌وری: تستر به Defectهای کم‌ارزش سوق داده می‌شود.
• نداشتن Oracle: هر رفتار عجیب به اشتباه Bug نامیده می‌شود.
• ضبط بی‌وقفه بدون امنیت: حجم زیاد و نشت داده ایجاد می‌کند.
• Debrief حذف‌شده: دانش در دفترچه تستر می‌ماند و تصمیم بعدی ساخته نمی‌شود.
• جایگزینی کامل Regression: خطاهای شناخته‌شده دوباره هزینه انسانی می‌گیرند.
• ادعای پوشش با تعداد Session: زمان صرف‌شده، سطح ریسک پوشش‌یافته را نشان نمی‌دهد.

چک‌لیست اجرای Session

• Charter به یک سؤال یا ریسک تصمیم‌پذیر وصل است.
• Build، محیط، Role و داده ثبت شده‌اند.
• Oracle و محدودیت دسترسی مشخص‌اند.
• Timebox و شرط توقف داریم.
• مدل پوشش اولیه ساخته شده است.
• Observation از Hypothesis جدا ثبت می‌شود.
• Artifactها فاقد Secret و داده شخصی‌اند.
• یافته مهم بازتولید یا عدم‌بازتولید آن ثبت شده است.
• Debrief مالک و اقدام بعدی می‌سازد.
• دانش پایدار به Regression یا مستند محصول برمی‌گردد.

پرسش‌های متداول

تفاوت تست اکتشافی و تست تصادفی چیست؟

تست اکتشافی با یادگیری، مدل، هدف و ارزیابی آگاهانه هدایت می‌شود. Ad-hoc ممکن است هدف داشته باشد، اما معمولاً ساختار و سابقه کمتری دارد. «تصادفی» توصیف دقیقی برای همه تست‌های Ad-hoc نیست.

یک Session اکتشافی چقدر طول بکشد؟

قانون جهانی وجود ندارد. برای شروع، ۴۵ تا ۶۰ دقیقه تمرکز همراه با آماده‌سازی و Debrief کوتاه مناسب است. پیچیدگی، خطر و توان تمرکز تیم باید مدت را تعیین کند.

آیا تست اکتشافی قابل اندازه‌گیری است؟

بله، اگر مخرج روشن باشد: زمان، ناحیه، ریسک، Role، State و داده پوشش‌داده‌شده، موانع و یافته‌های قابل‌اقدام را ثبت کنید. تعداد باگ یا Session به‌تنهایی معیار اثربخشی نیست.

آیا تست اکتشافی باید مستند شود؟

بله، اما مستندسازی باید از تصمیم و بازتولید پشتیبانی کند، نه جریان فکر را متوقف سازد. Charter، یادداشت زمان‌دار، مدل پوشش، Artifactهای ضروری و Debrief معمولاً کافی‌اند.

آیا می‌توان تست اکتشافی را خودکار کرد؟

خود یادگیری و طراحی لحظه‌ای انسان را نمی‌توان به یک Script ثابت تقلیل داد، اما ابزارها می‌توانند داده بسازند، Log جمع کنند و Setup را سریع کنند. یافته‌های پایدار و پرتکرار نیز می‌توانند به تست خودکار مناسب تبدیل شوند.

جمع‌بندی

تست اکتشافی حرفه‌ای یعنی آزادی همراه با پاسخ‌گویی: یک Charter روشن، مدل پوشش، Oracle، یادداشت امن و Debrief. با Session کوچک شروع کنید، روی یک ریسک واقعی تمرکز کنید و دانشی را که به دست می‌آورید به Bug، سؤال محصول، Regression یا Charter بعدی تبدیل کنید. هدف، «پیداکردن بیشترین باگ» نیست؛ هدف، ساختن اطلاعات باارزش برای تصمیم کیفیت است.