تست اکتشافی (Exploratory Testing) چیست؟ آموزش کامل + مثال واقعی

💥 همه چیز طبق برنامه پیش رفته بود…

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

اما کمتر از یک ساعت پس از انتشار، اولین تماس از واحد پشتیبانی رسید:

«کاربران نمی‌توانند سفارش خود را نهایی کنند.»

این اتفاق آن‌قدر رایج است که تقریباً هر تیم توسعه نرم‌افزار، حداقل یک‌بار آن را تجربه کرده است.

شاید اولین سؤال این باشد:

اگر همه تست‌ها با موفقیت انجام شده بودند، این Bug از کجا آمده است؟

پاسخ معمولاً در یک نکته مهم پنهان است:

تمام تست‌ها فقط چیزهایی را بررسی کرده بودند که تیم از قبل به آن‌ها فکر کرده بود.

اما کاربران واقعی هیچ‌وقت دقیقاً مانند سناریوهای از پیش طراحی‌شده رفتار نمی‌کنند.

ممکن است کاربری چند بار پشت سر هم روی دکمه پرداخت کلیک کند، هنگام ثبت سفارش مرورگر را Refresh کند، اینترنتش برای چند ثانیه قطع شود یا اطلاعاتی وارد کند که هیچ‌کس هنگام نوشتن Test Case انتظارش را نداشته است.

دقیقاً همین رفتارهای غیرقابل پیش‌بینی هستند که بسیاری از باگ‌های مهم را آشکار می‌کنند.

اینجاست که Exploratory Testing (تست اکتشافی) وارد میدان می‌شود.

برخلاف تصور رایج، تست اکتشافی به معنی «تست کردن بدون برنامه» یا «کلیک کردن تصادفی» نیست. در این روش، تستر با تکیه بر دانش محصول، تجربه، تحلیل ریسک و کنجکاوی حرفه‌ای، هم‌زمان با یادگیری سیستم، سناریوهای تست را طراحی و اجرا می‌کند.

هدف این نیست که فقط چند Bug پیدا شود؛ هدف، کشف ریسک‌ها، رفتارهای پیش‌بینی‌نشده و نقاط ضعفی است که ممکن است از دید سایر روش‌های تست پنهان مانده باشند.

به همین دلیل، Exploratory Testing در بسیاری از تیم‌های QA می‌تواند در کنار Manual Testing، Scripted Testing و Automation Testing استفاده شود تا تصویر کامل‌تری از کیفیت محصول به دست آید.

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

🎯 این مقاله برای چه کسانی مناسب است؟

فرقی نمی‌کند که به‌تازگی وارد دنیای تست نرم‌افزار شده باشید یا چند سال سابقه کار در حوزه QA داشته باشید؛ اگر می‌خواهید بدانید چگونه یک تستر حرفه‌ای فراتر از اجرای Test Caseها فکر می‌کند، این مقاله برای شماست.

در ادامه یاد خواهید گرفت:

• ✅ Exploratory Testing دقیقاً چیست و چه تفاوتی با سایر روش‌های تست دارد.
• ✅ چرا این رویکرد در پروژه‌های واقعی اهمیت دارد.
• ✅ یک QA Engineer حرفه‌ای چگونه یک Session تست اکتشافی را برنامه‌ریزی و اجرا می‌کند.
• ✅ چرا بعضی شرکت‌ها Exploratory Testing را اتلاف وقت می‌دانند و این دیدگاه چه ایرادهایی دارد.
• ✅ در چه شرایطی این روش بیشترین ارزش را ایجاد می‌کند.
• ✅ چگونه Exploratory Testing را با Test Case، Automation Testing و Agile Testing ترکیب کنیم.

💡 هدف این مقاله فقط معرفی Exploratory Testing نیست؛ هدف این است که به شما کمک کند مانند یک QA Engineer حرفه‌ای به کیفیت نرم‌افزار فکر کنید.

📘 Exploratory Testing چیست؟

فرض کنید قرار است کیفیت یک نرم‌افزار را بررسی کنید.

دو رویکرد کلی پیش روی شما وجود دارد.

در رویکرد اول، مجموعه‌ای از Test Caseها از قبل آماده شده‌اند. شما آن‌ها را به ترتیب اجرا می‌کنید و بررسی می‌کنید که نتیجه واقعی با نتیجه مورد انتظار مطابقت دارد یا خیر.

اما در رویکرد دوم، همه چیز به اجرای سناریوهای از پیش نوشته‌شده محدود نمی‌شود.

شما هنگام کار با نرم‌افزار، رفتار آن را مشاهده می‌کنید، سؤال‌های جدیدی در ذهنتان شکل می‌گیرد، فرضیه می‌سازید و بر اساس اطلاعاتی که به دست آورده‌اید تصمیم می‌گیرید مرحله بعد چه چیزی را آزمایش کنید.

این دقیقاً همان چیزی است که Exploratory Testing را شکل می‌دهد.

به زبان ساده، Exploratory Testing یک رویکرد تست نرم‌افزار است که در آن یادگیری، طراحی تست و اجرای تست به‌صورت هم‌زمان و پویا انجام می‌شوند.

به جای اینکه تستر صرفاً مجری سناریوهای از پیش تعریف‌شده باشد، نقش یک تحلیلگر و کاوشگر را بر عهده می‌گیرد؛ کسی که تلاش می‌کند رفتارهای غیرمنتظره، ریسک‌های پنهان و مسیرهایی را کشف کند که احتمالاً در هیچ Test Caseای ثبت نشده‌اند.

📖 تعریف ساده Exploratory Testing

اگر بخواهیم Exploratory Testing را در یک جمله تعریف کنیم:

Exploratory Testing یعنی یادگیری، فکر کردن و تست کردن به‌صورت هم‌زمان، با هدف کشف رفتارها، ریسک‌ها و سناریوهایی که از قبل به‌طور کامل پیش‌بینی نشده‌اند.

📚 تعریف حرفه‌ای

در Exploratory Testing، تستر به‌صورت هم‌زمان درباره سیستم یاد می‌گیرد، تست طراحی می‌کند و آن را اجرا می‌کند. اطلاعاتی که در طول تست به دست می‌آید، روی تصمیم‌های بعدی اثر می‌گذارد و مسیر ادامه Session را شکل می‌دهد.

نکته کلیدی این تعریف، پویایی فرآیند است. تستر از ابتدا همه مسیرها را نمی‌داند و هر کشف جدید می‌تواند باعث ایجاد یک فرضیه یا مسیر تست جدید شود.

در بسیاری از رویکردهای ساختاریافته، ابتدا تست طراحی می‌شود و سپس اجرا می‌شود؛ اما در Exploratory Testing، طراحی و اجرا دائماً بر اساس یادگیری‌های جدید روی یکدیگر تأثیر می‌گذارند.

🧠 طرز فکر یک QA حرفه‌ای

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

«کدام Test Case را بعد از این اجرا کنم؟»

اما یک QA حرفه‌ای سؤال‌های متفاوتی مطرح می‌کند:

• اگر کاربر برخلاف انتظار ما رفتار کند چه می‌شود؟
• کدام بخش این Feature بیشترین ریسک را دارد؟
• اگر بخواهم این قابلیت را خراب کنم، از کجا شروع می‌کنم؟
• چه سناریویی وجود دارد که احتمالاً هنوز هیچ‌کس آن را امتحان نکرده است؟
• اگر یکی از فرضیات اصلی ما اشتباه باشد، رفتار سیستم چگونه خواهد بود؟

تفاوت اصلی یک Exploratory Tester حرفه‌ای، در کیفیت سؤال‌هایی است که مطرح می‌کند، نه در تعداد کلیک‌هایی که انجام می‌دهد.

🧪 مثال عملی

فرض کنید در حال تست صفحه ورود یک فروشگاه اینترنتی هستید.

یک Test Case معمولی ممکن است شامل این مراحل باشد:

1. نام کاربری معتبر وارد کنید.
2. رمز عبور معتبر وارد کنید.
3. روی دکمه Login کلیک کنید.
4. بررسی کنید که کاربر وارد حساب خود شده باشد.

این سناریو کاملاً درست است، اما فقط یکی از رفتارهای مورد انتظار را بررسی می‌کند.

حالا یک تستر در یک Session اکتشافی ممکن است سؤال‌های دیگری مطرح کند:

• اگر رمز عبور را چندین بار اشتباه وارد کنم چه اتفاقی می‌افتد؟
• اگر هنگام ورود، اینترنت قطع شود چه می‌شود؟
• اگر هم‌زمان در دو مرورگر Login کنم چه رفتاری رخ می‌دهد؟
• اگر دکمه Login را چند بار پشت سر هم فشار دهم، سیستم چگونه واکنش نشان می‌دهد؟
• اگر کاربر ایمیل را با فاصله یا حروف بزرگ وارد کند چه می‌شود؟
• آیا پیام‌های خطا برای کاربر واضح و قابل فهم هستند؟

ممکن است بخشی از این سناریوها در Test Caseهای اولیه وجود نداشته باشند؛ اما دقیقاً همین مسیرهای غیرمنتظره می‌توانند سرنخ‌هایی برای کشف ریسک‌های جدید ایجاد کنند.

💡 توصیه حرفه‌ای

هدف Exploratory Testing این نیست که در هر Session حتماً Bug پیدا کنید؛ هدف این است که ریسک‌های ناشناخته را بررسی کنید. گاهی ارزشمندترین نتیجه یک Session این است که متوجه شوید یک بخش مهم، حتی در شرایط غیرعادی، رفتار قابل قبولی دارد.

📌 خلاصه این بخش

• ✅ Exploratory Testing یک رویکرد برای تست نرم‌افزار است.
• ✅ در این رویکرد، یادگیری، طراحی تست و اجرای تست به‌صورت پویا و مرتبط با یکدیگر انجام می‌شوند.
• ✅ تستر می‌تواند بر اساس یافته‌های جدید، مسیر تست را در طول Session تغییر دهد.
• ✅ هدف اصلی فقط پیدا کردن Bug نیست؛ بلکه کشف ریسک‌ها، ناشناخته‌ها و رفتارهای پیش‌بینی‌نشده نیز اهمیت دارد.

🕰️ چرا Exploratory Testing به وجود آمد؟

قبل از اینکه Exploratory Testing به‌عنوان یک رویکرد شناخته شود، بسیاری از تیم‌های نرم‌افزاری بخش مهمی از فعالیت‌های تست خود را بر پایه Test Caseهای از پیش نوشته‌شده انجام می‌دادند.

این روش هنوز هم یکی از پایه‌های مهم تست نرم‌افزار است و در بسیاری از پروژه‌ها، به‌ویژه پروژه‌هایی که نیاز به تکرارپذیری و شواهد رسمی دارند، نقش مهمی ایفا می‌کند.

اما یک سؤال مهم وجود دارد:

🤔 اگر فقط چیزهایی را تست کنیم که از قبل به آن‌ها فکر کرده‌ایم، چه کسی مسئول کشف چیزهایی است که هنوز به ذهنمان نرسیده‌اند؟

همین سؤال یکی از پایه‌های مهم شکل‌گیری نگاه اکتشافی به تست نرم‌افزار است.

🚀 مشکل فقط Test Case نبود

یکی از بزرگ‌ترین سوءبرداشت‌ها این است که تصور کنیم Exploratory Testing برای جایگزین کردن Test Caseها به وجود آمده است.

❌ این تصور درست نیست.

Test Caseها مشکل نیستند؛ اما محدودیت‌های خودشان را دارند.

هر Test Case بر اساس دانش، تجربه و فرضیات نویسنده آن طراحی می‌شود. اگر هنگام طراحی یک سناریوی خاص در نظر گرفته نشده باشد، احتمال زیادی وجود دارد که همان سناریو نیز هرگز اجرا نشود.

به عبارت ساده:

Test Caseها معمولاً بر اساس چیزی طراحی می‌شوند که تیم از قبل می‌داند، انتظار دارد یا پیش‌بینی کرده است.

اما نرم‌افزارهای واقعی همیشه در محدوده پیش‌بینی‌های ما باقی نمی‌مانند.

🌍 دنیای واقعی از Test Caseها پیچیده‌تر است

کاربران واقعی همیشه مطابق سناریوهای ایده‌آل رفتار نمی‌کنند.

• ممکن است چند دکمه را پشت سر هم فشار دهند.
• وسط یک فرآیند صفحه را Refresh کنند.
• از مرورگر یا دستگاه دیگری ادامه دهند.
• اطلاعات غیرمنتظره وارد کنند.
• اینترنت ضعیف یا ناپایدار داشته باشند.
• فرآیندی را در زمانی متوقف کنند که تیم انتظارش را نداشته است.
• دو عملیات را تقریباً هم‌زمان انجام دهند.

همین رفتارهای غیرقابل پیش‌بینی باعث می‌شوند اجرای صرف Test Caseها همیشه برای شناخت کامل رفتار یک محصول کافی نباشد.

🧠 تغییر نگاه از «اجرای تست» به «کشف ریسک»

با پیچیده‌تر شدن نرم‌افزارها، نقش تستر نیز از یک مجری صرف سناریوها فراتر رفت.

یک QA Engineer فقط بررسی نمی‌کند که آیا نرم‌افزار مطابق مستندات عمل می‌کند یا خیر؛ او باید بتواند درباره ریسک، رفتار کاربر و شرایط شکست نیز سؤال بپرسد.

برای مثال:

• بزرگ‌ترین ریسک این قابلیت چیست؟
• کاربر از چه مسیرهایی ممکن است سیستم را دچار مشکل کند؟
• اگر همه چیز طبق مستندات درست باشد، آیا باز هم ممکن است تجربه کاربری نامناسبی وجود داشته باشد؟
• آیا شرایطی وجود دارد که هنوز کسی آن را آزمایش نکرده باشد؟

این تغییر نگاه، پایه مهمی برای رشد رویکردهای اکتشافی در تست نرم‌افزار ایجاد کرد.

⚡ تغییرات سریع و نیاز به بازخورد سریع‌تر

با گسترش رویکردهای Agile و چرخه‌های کوتاه‌تر توسعه، تیم‌ها با تغییرات بیشتری روبه‌رو شدند.

وقتی یک Feature در مدت کوتاهی توسعه پیدا می‌کند، ممکن است نیازمندی‌ها تغییر کنند، طراحی اصلاح شود یا رفتار سیستم در طول کار تکامل پیدا کند.

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

Exploratory Testing می‌تواند در چنین شرایطی به تیم کمک کند تا در کنار تست‌های ساختاریافته، سریع‌تر از ریسک‌ها و رفتارهای پیش‌بینی‌نشده اطلاعات به دست آورد.

🧪 یک مثال ساده

فرض کنید تیم شما قابلیت «ورود با حساب گوگل» را به یک اپلیکیشن اضافه کرده است.

Test Caseهای اصلی ممکن است سناریوهایی مانند این‌ها را پوشش دهند:

• ورود موفق
• لغو ورود
• خطای احراز هویت
• حساب غیرفعال

اما یک QA ممکن است سؤال‌های دیگری مطرح کند:

• اگر کاربر هنگام احراز هویت مرورگر را ببندد چه می‌شود؟
• اگر ارتباط با سرویس احراز هویت موقتاً قطع شود چه؟
• اگر کاربر در دو دستگاه مختلف هم‌زمان Login باشد چه اتفاقی می‌افتد؟
• اگر Session قبلی هنوز معتبر باشد، رفتار سیستم چگونه خواهد بود؟

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

🧠 طرز فکر یک QA حرفه‌ای

یک تستر حرفه‌ای فقط نمی‌پرسد: «آیا این قابلیت کار می‌کند؟»

او می‌پرسد: «در چه شرایطی ممکن است این قابلیت از کار بیفتد؟»

همین تفاوت در نوع سؤال‌ها، مرز مهمی بین اجرای تست و کشف ریسک است.

❌ باور اشتباه

«اگر Test Caseها کامل باشند، دیگر نیازی به Exploratory Testing نیست.»

✅ واقعیت

Test Caseهای کامل و باکیفیت بسیار ارزشمند هستند، اما نمی‌توان انتظار داشت تمام رفتارهای ممکن کاربران، شرایط محیطی و تعاملات پیش‌بینی‌نشده را پوشش دهند.

Exploratory Testing برای حذف Test Caseها به وجود نیامده است؛ هدف آن، کمک به کشف بخش‌هایی از ریسک است که ممکن است در تست‌های از پیش طراحی‌شده دیده نشده باشند.

📌 خلاصه این بخش

• ✅ Test Caseها ابزارهای ارزشمندی هستند، اما محدودیت دارند.
• ✅ رفتار کاربران واقعی همیشه قابل پیش‌بینی نیست.
• ✅ پیچیدگی بیشتر نرم‌افزار و تغییرات سریع، نیاز به رویکردهای منعطف‌تر تست را افزایش می‌دهد.
• ✅ Exploratory Testing برای جایگزین کردن تست‌های ساختاریافته ایجاد نشده است؛ بلکه می‌تواند برای کشف ریسک‌ها و سناریوهای ناشناخته در کنار آن‌ها استفاده شود.

🧠 فلسفه Exploratory Testing؛ چرا این روش فقط یک تکنیک تست نیست؟

وقتی برای اولین بار نام Exploratory Testing را می‌شنوید، ممکن است تصور کنید این هم فقط یکی دیگر از تکنیک‌های تست نرم‌افزار است؛ درست مانند Regression Testing، Smoke Testing یا Boundary Value Analysis.

اما این تصور کاملاً دقیق نیست.

Exploratory Testing قبل از آنکه فقط یک تکنیک باشد، یک طرز فکر (Mindset) است.

در این رویکرد، تستر فقط وظیفه ندارد مراحل از پیش تعیین‌شده را اجرا کند؛ بلکه باید مانند یک تحلیلگر و کاوشگر رفتار سیستم را بررسی کند، فرضیه بسازد و به دنبال پاسخ پرسش‌هایی باشد که ممکن است هنوز هیچ‌کس آن‌ها را مطرح نکرده باشد.

به همین دلیل، تفاوت اصلی یک تستر حرفه‌ای با یک تستر تازه‌کار فقط در تعداد ابزارهایی که می‌شناسد یا تعداد Test Caseهایی که اجرا کرده نیست؛ بلکه در نوع نگاه و کیفیت سؤال‌هایی است که مطرح می‌کند.

🎯 هدف اصلی Exploratory Testing چیست؟

یکی از رایج‌ترین برداشت‌های اشتباه این است که هدف این روش فقط پیدا کردن Bug است.

❌ این نگاه کامل نیست.

اگر تنها معیار موفقیت یک Session، تعداد Bugهای ثبت‌شده باشد، ممکن است تستر برای افزایش آمار، زمان زیادی را صرف مشکلات کم‌اهمیت کند و در مقابل از ریسک‌های مهم محصول غافل شود.

هدف اصلی Exploratory Testing، کمک به کاهش ریسک و افزایش شناخت تیم از رفتار محصول است.

گاهی این کاهش ریسک با پیدا کردن یک Bug بحرانی اتفاق می‌افتد و گاهی با بررسی یک قابلیت در شرایط غیرعادی و اطمینان بیشتر نسبت به رفتار آن.

🧩 تفاوت نگاه یک مجری تست با یک QA Engineer

فرض کنید از دو نفر بخواهید صفحه ثبت سفارش یک فروشگاه اینترنتی را بررسی کنند.

👤 نفر اول

او Test Caseهای موجود را باز می‌کند و دقیقاً همان مراحلی را که نوشته شده‌اند اجرا می‌کند.

اگر همه مراحل موفق باشند، نتیجه را Pass ثبت می‌کند و سراغ مورد بعدی می‌رود.

👨‍💻 نفر دوم

او علاوه بر اجرای تست‌های موجود، مدام از خودش سؤال می‌پرسد:

• اگر کاربر دو بار روی دکمه «ثبت سفارش» کلیک کند چه می‌شود؟
• اگر قیمت محصول در همان لحظه تغییر کند چه اتفاقی می‌افتد؟
• اگر Session کاربر منقضی شده باشد، آیا پیام مناسبی نمایش داده می‌شود؟
• آیا امکان ثبت سفارش تکراری وجود دارد؟
• اگر کاربر با دکمه Back مرورگر برگردد، وضعیت سفارش چگونه خواهد بود؟

از نظر ظاهری، هر دو نفر در حال تست یک Feature هستند؛ اما نوع سؤال‌هایی که از سیستم می‌پرسند، متفاوت است.

🧠 طرز فکر یک QA حرفه‌ای

یک QA حرفه‌ای فقط نمی‌پرسد «چه چیزی را تست کنم؟»؛ او می‌پرسد «کدام ریسک را هنوز بررسی نکرده‌ام؟»

🚫 اشتباه رایج

بعضی افراد تصور می‌کنند:

«هرچه بیشتر روی بخش‌های مختلف نرم‌افزار کلیک کنیم، Exploratory Testing بهتری انجام داده‌ایم.»

در واقعیت، تعداد کلیک‌ها معیار کیفیت نیست.

ممکن است یک تستر در ده دقیقه، با چند سؤال هوشمندانه یک ریسک مهم را کشف کند و تستر دیگری در دو ساعت فقط مسیرهای تکراری را طی کند، بدون اینکه اطلاعات ارزشمند جدیدی به دست آورد.

❌ باور اشتباه

«Exploratory Testing یعنی تست کردن بدون برنامه.»

✅ واقعیت

یک Session حرفه‌ای می‌تواند هدف مشخص، محدوده، Time Box، Charter و روش ثبت یافته‌ها داشته باشد.

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

🔄 سه فعالیت اصلی در Exploratory Testing؛ Learning، Test Design و Execution

یکی از مهم‌ترین تفاوت‌های Exploratory Testing با بسیاری از روش‌های سنتی تست نرم‌افزار، نحوه ارتباط میان فعالیت‌های تست است.

در یک فرآیند ساختاریافته، ممکن است ابتدا Test Case طراحی شود، سپس اجرا شود و در پایان نتایج بررسی شوند.

در Exploratory Testing، این فعالیت‌ها کاملاً از هم جدا نیستند؛ بلکه تستر در طول Session به‌طور مداوم یاد می‌گیرد، بر اساس یادگیری خود تست طراحی می‌کند و نتیجه آن را اجرا می‌کند.

🔄 چرخه اصلی Exploratory Testing

Learning → Test Design → Execution → Observation → Learning Again ↺

هر کشف جدید می‌تواند مسیر ادامه تست را تغییر دهد و باعث شود تستر سؤال‌های تازه‌ای مطرح کند.

به همین دلیل، یک Session موفق اغلب یک مسیر کاملاً خطی ندارد؛ بلکه مانند یک چرخه یادگیری و کشف پیش می‌رود.

1️⃣ Learning؛ یادگیری

هر Session با یادگیری شروع می‌شود؛ اما منظور از یادگیری فقط مطالعه مستندات نیست.

یک QA حرفه‌ای تلاش می‌کند محصول، Feature، کاربران، قوانین کسب‌وکار و وابستگی‌های مهم آن را بهتر بشناسد.

• این قابلیت دقیقاً چه کاری انجام می‌دهد؟
• چه کسانی از آن استفاده می‌کنند؟
• مهم‌ترین ریسک آن چیست؟
• به چه سرویس‌هایی وابسته است؟
• اگر خراب شود، چه تأثیری روی کسب‌وکار خواهد داشت؟

🎯 مثال

فرض کنید قرار است قابلیت «پرداخت آنلاین» را تست کنید.

اگر فقط بدانید این صفحه سفارش را ثبت می‌کند، احتمالاً سناریوهای محدودی را بررسی خواهید کرد.

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

حالا ممکن است این سؤال‌ها به ذهن شما برسد:

• اگر پرداخت موفق شود ولی Callback دریافت نشود چه؟
• اگر پرداخت دوبار ارسال شود چه؟
• اگر موجودی کالا هم‌زمان تغییر کند چه؟
• اگر سرویس پیامک در دسترس نباشد چه؟

2️⃣ Test Design؛ طراحی تست

بر اساس اطلاعاتی که در مرحله Learning به دست آمده، تستر تصمیم می‌گیرد چه چیزی را بررسی کند.

این طراحی در Exploratory Testing می‌تواند بسیار پویا باشد.

«اگر این قسمت با Session کاربر ارتباط دارد، بهتر است انقضای Session را هم بررسی کنم.»

«اگر قیمت بعد از انتخاب کد تخفیف تغییر می‌کند، شاید تغییر تعداد کالا هم روی مبلغ نهایی اثر بگذارد.»

این تصمیم‌ها ممکن است در طول Session چندین بار تغییر کنند؛ زیرا هر یافته جدید می‌تواند سناریوهای تازه‌ای ایجاد کند.

🧠 طرز فکر یک QA حرفه‌ای

یک QA حرفه‌ای به‌جای اینکه فقط بپرسد:

«چه چیزی را تست کنم؟»

از خودش می‌پرسد:

«اگر این فرضیه درست نباشد، چه اتفاقی می‌افتد؟»

همین سؤال ساده می‌تواند یک مسیر تست جدید ایجاد کند.

3️⃣ Execution؛ اجرای تست

حالا زمان اجرای سناریوهاست.

اما حتی هنگام اجرا نیز تستر نباید فقط به دنبال Pass یا Fail باشد.

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

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

این مشاهده می‌تواند سؤال‌های جدیدی ایجاد کند:

• آیا این محدودیت بعد از مدتی برداشته می‌شود؟
• اگر کاربر رمز عبور را بازیابی کند چه؟
• اگر از دستگاه دیگری وارد شود چه؟
• آیا مدیر سیستم می‌تواند حساب را باز کند؟
• آیا پیام نمایش‌داده‌شده برای کاربر واضح است؟

در نتیجه، Execution دوباره به Learning و Test Design متصل می‌شود و چرخه ادامه پیدا می‌کند.

💡 هر کشف، یک مسیر جدید ایجاد می‌کند

این دقیقاً همان چیزی است که Exploratory Testing را از اجرای صرف Test Case متمایز می‌کند.

• هر مشاهده می‌تواند یک سؤال جدید ایجاد کند.
• هر سؤال می‌تواند یک فرضیه جدید ایجاد کند.
• هر فرضیه می‌تواند به یک تست جدید منجر شود.
• هر تست می‌تواند اطلاعات بیشتری درباره سیستم آشکار کند.

🚫 اشتباه رایج

بعضی تسترها تصور می‌کنند باید تا پایان Session دقیقاً همان مسیر اولیه را دنبال کنند. در حالی که در Exploratory Testing، تغییر مسیر بر اساس شواهد جدید نه‌تنها مجاز است، بلکه بخش مهمی از ماهیت این رویکرد است.

❌ باور اشتباه

«اگر از قبل همه مراحل مشخص نباشند، تست قابل اعتماد نیست.»

✅ واقعیت

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

انعطاف در مسیر تست زمانی ارزشمند است که بر اساس شواهد و یادگیری جدید اتفاق بیفتد.

📌 خلاصه این بخش

• ✅ Exploratory Testing بر پایه یک چرخه مداوم از Learning، Test Design و Execution شکل می‌گیرد.
• ✅ اطلاعاتی که در طول تست به دست می‌آید، مسیر ادامه تست را تغییر می‌دهد.
• ✅ تغییر مسیر Session باید هدفمند و مبتنی بر شواهد باشد.
• ✅ ساختار داشتن Exploratory Testing به معنی از پیش تعیین کردن تمام مراحل اجرا نیست.

🚀 چگونه Exploratory Testing را در یک پروژه واقعی انجام دهیم؟

بعد از آشنایی با مفهوم و فلسفه Exploratory Testing، سؤال مهم این است:

در عمل، یک QA Engineer چگونه یک Session تست اکتشافی را اجرا می‌کند؟

بعضی افراد تصور می‌کنند پاسخ این سؤال ساده است:

«برنامه را باز کن و هر کاری به ذهنت رسید انجام بده.»

اما این دقیقاً همان برداشتی است که باعث می‌شود Exploratory Testing با تست تصادفی یا Ad-hoc Testing اشتباه گرفته شود.

یک Session حرفه‌ای، حتی اگر در مسیر خود انعطاف‌پذیر باشد، معمولاً هدف، محدوده و زمان مشخصی دارد.

📝 مرحله ۱: هدف Session را مشخص کنید

قبل از اینکه حتی یک کلیک انجام دهید، از خودتان بپرسید:

امروز دقیقاً به دنبال چه چیزی هستم؟

هدف نباید بیش از حد کلی باشد.

❌ مثال نامناسب:

«می‌خواهم کل سیستم را تست کنم.»

✅ مثال مناسب:

• بررسی ریسک‌های فرآیند ثبت سفارش
• ارزیابی مدیریت خطاهای Login
• بررسی رفتار سیستم هنگام قطع اینترنت
• کشف مشکلات تجربه کاربری در صفحه پرداخت
• بررسی رفتار Session هنگام تغییر وضعیت کاربر

هرچه هدف شفاف‌تر باشد، تمرکز Session بیشتر خواهد بود.

📍 مرحله ۲: محدوده تست را مشخص کنید

یکی از اشتباهات رایج این است که تستر بدون مرز مشخص وارد سیستم شود.

نتیجه ممکن است این باشد که بعد از یک ساعت، مشخص نباشد چه چیزی بررسی شده و چه چیزهایی هنوز ناشناخته هستند.

بهتر است محدوده‌ای مانند این‌ها مشخص شود:

• فقط صفحه Login
• فقط فرآیند پرداخت
• فقط مدیریت پروفایل
• فقط APIهای احراز هویت
• فقط پنل مدیریت کاربران

مشخص کردن Scope باعث می‌شود Session تمرکز بیشتری داشته باشد و گزارش آن نیز واضح‌تر باشد.

🔍 مرحله ۳: سیستم را مشاهده و یادگیری را آغاز کنید

قبل از اینکه بخواهید سیستم را «خراب» کنید، ابتدا آن را بشناسید.

از خودتان بپرسید:

• این قابلیت چه هدفی دارد؟
• چه کسی از آن استفاده می‌کند؟
• مهم‌ترین ریسک آن چیست؟
• چه وابستگی‌هایی دارد؟
• اگر این بخش از کار بیفتد، چه اتفاقی برای کسب‌وکار می‌افتد؟

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

🧠 مرحله ۴: فرضیه بسازید

حالا به‌جای اجرای کورکورانه عملیات، فرضیه‌سازی کنید.

• اگر کاربر دوبار روی دکمه پرداخت کلیک کند چه می‌شود؟
• اگر مرورگر ناگهان بسته شود چه؟
• اگر Session منقضی شود چه؟
• اگر اینترنت قطع شود چه؟
• اگر اطلاعات ناقص ارسال شود چه؟
• اگر دو کاربر هم‌زمان یک عملیات را انجام دهند چه؟

هر فرضیه می‌تواند یک مسیر جدید برای تست ایجاد کند.

▶️ مرحله ۵: فرضیه را آزمایش کنید

حالا زمان اجرای تست است.

اما هنگام اجرا فقط به دنبال Bug نباشید.

به این موارد نیز توجه کنید:

• رفتار سیستم
• پیام‌های خطا
• لاگ‌ها در صورت دسترسی
• تجربه کاربری
• عملکرد (Performance)
• سازگاری با مرورگرها یا دستگاه‌های مختلف

گاهی حتی اگر Bugی پیدا نشود، یک رفتار غیرمنتظره می‌تواند سرنخی برای ادامه تست باشد.

📝 مرحله ۶: مشاهدات را ثبت کنید

یکی از تفاوت‌های یک Session حرفه‌ای با تست بی‌هدف، ثبت نتایج و مشاهدات است.

در طول Session بهتر است ثبت کنید:

• چه چیزی را بررسی کردید؟
• چه فرضیه‌هایی را آزمایش کردید؟
• چه رفتارهای جالب یا غیرمنتظره‌ای مشاهده شد؟
• چه Bugهایی پیدا شدند؟
• چه سؤال‌هایی برای بررسی بعدی ایجاد شدند؟

این اطلاعات برای بازتولید تست، اشتراک‌گذاری با تیم و تصمیم‌گیری درباره تست‌های بعدی ارزشمند هستند.

🔄 مرحله ۷: مسیر تست را بر اساس یافته‌ها تغییر دهید

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

همین کشف، سؤال‌های جدیدی ایجاد می‌کند:

• اگر اینترنت دوباره وصل شود چه؟
• اگر کاربر صفحه را Refresh کند چه؟
• اگر دوباره روی پرداخت کلیک کند چه؟
• آیا سفارش تکراری ثبت می‌شود؟
• آیا موجودی کالا کاهش پیدا می‌کند؟

در این لحظه، مسیر Session تغییر می‌کند؛ اما این تغییر بر اساس یک مشاهده و فرضیه جدید اتفاق افتاده است، نه بر اساس تصادف.

💡 نکته حرفه‌ای

پایان یک Session موفق، همیشه با Bug Report همراه نیست. گاهی ارزشمندترین خروجی Session، شناخت بهتر سیستم، کشف یک ریسک جدید یا ایجاد ایده برای Test Case و Automation است.

📌 خلاصه این بخش

• 🎯 هدف Session را مشخص کنید.
• 📍 Scope تست را تعیین کنید.
• 🔍 ابتدا سیستم را بشناسید.
• 🧠 بر اساس شناخت خود فرضیه بسازید.
• 🧪 فرضیه‌ها را آزمایش کنید.
• 📝 مشاهدات و یافته‌ها را ثبت کنید.
• 🔄 بر اساس یافته‌های جدید، مسیر تست را به‌صورت آگاهانه تغییر دهید.

🎬 یک Session واقعی Exploratory Testing؛ از شروع تا کشف یک Bug مهم

تا اینجا درباره مفهوم، فلسفه و مراحل Exploratory Testing صحبت کردیم. حالا بیایید یک Session واقعی را قدم‌به‌قدم دنبال کنیم تا ببینیم یک QA Engineer حرفه‌ای در عمل چگونه فکر می‌کند.

فرض کنید قرار است قابلیت پرداخت آنلاین یک فروشگاه اینترنتی را قبل از انتشار نسخه جدید بررسی کنیم.

📝 مرحله اول: تعریف Mission

قبل از باز کردن مرورگر، QA هدف Session را مشخص می‌کند:

بررسی ریسک‌های فرآیند پرداخت آنلاین، به‌ویژه در شرایط غیرعادی و خطاهای ارتباطی.

محدوده Session:

• سبد خرید
• اعمال کد تخفیف
• انتخاب روش پرداخت
• درگاه بانکی
• بازگشت از درگاه
• ثبت نهایی سفارش

Time Box: ۴۵ دقیقه

🔍 مرحله دوم: شناخت Feature

QA قبل از شروع تست، چند دقیقه صرف شناخت مسیر پرداخت می‌کند.

سؤال‌های اولیه می‌توانند این‌ها باشند:

• اگر پرداخت ناموفق شود، وضعیت سفارش چه می‌شود؟
• چه زمانی موجودی کالا کاهش پیدا می‌کند؟
• چه زمانی سفارش به‌عنوان پرداخت‌شده ثبت می‌شود؟
• ارتباط بین سیستم سفارش، انبار و درگاه چگونه است؟
• اگر Callback درگاه دریافت نشود چه اتفاقی می‌افتد؟

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

🧠 مرحله سوم: اولین فرضیه

تستر اولین فرضیه را مطرح می‌کند:

اگر کاربر بعد از ورود به درگاه بانکی، دکمه Back مرورگر را بزند چه می‌شود؟

تست انجام می‌شود.

نتیجه: سیستم به صفحه پرداخت برمی‌گردد و مشکل واضحی دیده نمی‌شود.

اما حالا سؤال جدیدی شکل می‌گیرد:

اگر کاربر دوباره روی دکمه پرداخت کلیک کند چه؟

تست انجام می‌شود و دو درخواست پرداخت ارسال می‌شود.

در این مرحله هنوز مشخص نیست که این رفتار حتماً یک Bug است، اما یک سرنخ مهم ایجاد شده است.

⚡ مرحله چهارم: تغییر مسیر Session

تستر بر اساس یافته قبلی، فرضیه جدیدی مطرح می‌کند:

اگر ارتباط اینترنت هنگام بازگشت از درگاه قطع شود چه اتفاقی می‌افتد؟

تستر سناریو را اجرا می‌کند.

نتیجه مشاهده‌شده:

• سفارش در وضعیت Pending باقی می‌ماند.
• موجودی کالا کاهش پیدا می‌کند.
• وضعیت نهایی پرداخت برای کاربر مشخص نیست.

در این لحظه، یک رفتار مشکوک کشف شده است.

🔬 مرحله پنجم: بررسی و بازتولید

QA بلافاصله Bug Report ثبت نمی‌کند.

ابتدا تلاش می‌کند مشخص کند آیا این رفتار قابل تکرار است یا خیر.

• قطع اینترنت در زمان‌های مختلف
• تست روی مرورگر دیگر
• تست روی موبایل
• تست با چند محصول مختلف
• تکرار فرآیند با و بدون کد تخفیف

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

🐞 مرحله ششم: ثبت Bug Report

حالا زمان ثبت Bug است.

گزارش ضعیف:

❌ «پرداخت مشکل دارد.»

گزارش حرفه‌ای:

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

Bug Report بهتر است اطلاعاتی مانند موارد زیر را داشته باشد:

• عنوان واضح
• Preconditions
• Steps to Reproduce
• Actual Result
• Expected Result
• Test Environment
• Severity
• Priority
• Screenshot یا Video در صورت نیاز

📈 مرحله هفتم: پایان Bug نیست؛ شروع سؤال‌های جدید است

اینجا تفاوت یک QA حرفه‌ای با یک Bug Hunter ساده مشخص می‌شود.

بعد از کشف این مشکل، QA از خودش می‌پرسد:

• آیا ممکن است پرداخت تکراری هم رخ دهد؟
• آیا پیامک سفارش دوبار ارسال می‌شود؟
• آیا ایمیل تأیید دوبار ارسال می‌شود؟
• آیا امتیاز باشگاه مشتریان اشتباه محاسبه می‌شود؟
• آیا گزارش مالی تحت تأثیر قرار می‌گیرد؟
• آیا این الگو در سایر فرآیندهای پرداخت نیز وجود دارد؟

یک Bug ممکن است یک نقطه پایان نباشد؛ بلکه سرنخی باشد که چند مسیر جدید برای بررسی ایجاد می‌کند.

🧠 نگاه یک QA Senior

یک تستر تازه‌کار ممکن است بگوید: «یک Bug پیدا کردم.»

اما یک QA Senior از خودش می‌پرسد: «اگر این Bug وجود دارد، چه ریسک‌های دیگری ممکن است در همین بخش پنهان شده باشند؟»

📌 نتیجه یک Session موفق چیست؟

ارزش یک Session فقط به تعداد Bugهای پیدا‌شده محدود نمی‌شود.

• 🐞 کشف Bug
• ⚠️ کشف ریسک
• 🔍 شناخت بهتر محصول
• 📝 شناسایی شکاف‌های Test Case
• 🤖 ایجاد ایده برای Automation
• 🤝 افزایش درک تیم از رفتار سیستم

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

❌ آیا Exploratory Testing فقط اتلاف وقت است؟

اگر در یک شرکت نرم‌افزاری کار کرده باشید، ممکن است جمله‌هایی مانند این را شنیده باشید:

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

«همه Test Caseها Pass شده‌اند؛ دیگر چه چیزی مانده که تست کنیم؟»

«ما Automation داریم؛ نیازی به این کارها نیست.»

این دیدگاه‌ها گاهی از تجربه‌های ناموفق در اجرای بدون ساختار تست اکتشافی ناشی می‌شوند و گاهی نیز نتیجه برداشت نادرست از نقش QA هستند.

بیایید این باورها را دقیق‌تر بررسی کنیم.

❌ باور اول: «مشتری خودش باگ را پیدا می‌کند.»

در نگاه اول، این جمله ممکن است منطقی به نظر برسد. هزاران کاربر واقعی از محصول استفاده می‌کنند و ممکن است سناریوهایی را اجرا کنند که تیم QA هرگز فرصت بررسی آن‌ها را نداشته است.

اما سؤال مهم این است:

آیا واقعاً باید مشتری اولین کسی باشد که Bugهای مهم محصول را کشف می‌کند؟

وقتی مشتری یک مشکل مهم پیدا می‌کند، معمولاً فقط یک Bug کشف نشده است؛ بلکه ممکن است هزینه‌های دیگری نیز ایجاد شود:

• کاهش اعتماد کاربر
• افزایش درخواست‌های پشتیبانی
• درگیر شدن تیم توسعه با Hotfix
• اختلال در برنامه Release
• نیاز به بررسی داده‌ها و تراکنش‌های واقعی
• آسیب احتمالی به اعتبار برند

مشتری محصول را برای استفاده خریداری کرده است، نه برای اینکه جایگزین فرآیند QA شود.

💡 سؤال مهم برای تیم QA:

اگر یک ریسک مهم را امروز در داخل تیم پیدا نکنیم، احتمالاً چه کسی فردا آن را کشف خواهد کرد؟

❌ باور دوم: «همه Test Caseها Pass شده‌اند، پس محصول آماده انتشار است.»

Pass شدن Test Caseها نشان می‌دهد سناریوهایی که طراحی و اجرا شده‌اند، مطابق انتظار عمل کرده‌اند.

اما این موضوع به‌تنهایی ثابت نمی‌کند که تمام رفتارهای ممکن کاربران و شرایط محیطی بررسی شده‌اند.

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

❌ باور سوم: «Automation Testing همه چیز را پوشش می‌دهد.»

Automation Testing یکی از ارزشمندترین ابزارهای QA است، اما یک تست خودکار معمولاً چیزی را اجرا می‌کند که از قبل برای آن طراحی شده است.

یک تست خودکار می‌تواند به‌سرعت هزاران بار یک سناریوی مشخص را اجرا کند؛ اما Exploratory Testing به دنبال کشف سناریوهایی است که ممکن است هنوز در Automation Suite وجود نداشته باشند.

به همین دلیل، این دو رویکرد را بهتر است مکمل یکدیگر بدانیم:

Automation برای تکرار سریع و قابل اعتماد سناریوهای شناخته‌شده

Exploratory Testing برای کشف ریسک‌ها و رفتارهای ناشناخته

❌ باور چهارم: «Exploratory Testing یعنی کلیک کردن تصادفی.»

اگر تستر بدون هدف، بدون Scope، بدون Time Box و بدون ثبت یافته‌ها فقط بین صفحات مختلف جابه‌جا شود، این فعالیت لزوماً Exploratory Testing حرفه‌ای محسوب نمی‌شود.

یک Session حرفه‌ای می‌تواند شامل موارد زیر باشد:

• 🎯 هدف مشخص
• 📍 Scope مشخص
• ⏱️ Time Box
• 📝 ثبت مشاهدات
• 🧠 تحلیل یافته‌ها
• 📋 گزارش نتایج

آنچه از قبل قابل پیش‌بینی نیست، نتیجه و مسیر دقیق کشف است؛ نه اینکه Session بدون هدف اجرا شود.

❌ باور پنجم: «اگر Bug پیدا نشود، زمان هدر رفته است.»

این نگاه، ارزش QA را فقط با تعداد Bugهای ثبت‌شده اندازه می‌گیرد.

فرض کنید یک Session هدفمند روی فرآیند بازیابی رمز عبور انجام داده‌اید و Bug مهمی پیدا نکرده‌اید.

اگر Session باعث شده باشد ریسک‌های اصلی بررسی شوند، رفتار سیستم بهتر شناخته شود و تیم اطمینان بیشتری نسبت به محصول پیدا کند، نمی‌توان گفت این زمان بی‌ارزش بوده است.

کاهش عدم‌قطعیت و افزایش شناخت تیم از محصول نیز می‌توانند بخشی از ارزش فعالیت QA باشند.

❌ باور ششم: «فقط QAهای Senior می‌توانند Exploratory Testing انجام دهند.»

تجربه بیشتر معمولاً باعث می‌شود تستر سریع‌تر ریسک‌ها را تشخیص دهد و سؤال‌های بهتری مطرح کند؛ اما Exploratory Testing مهارتی است که افراد تازه‌کار نیز می‌توانند آن را یاد بگیرند.

استفاده از Charter، Checklist، Heuristic و دریافت بازخورد از QAهای باتجربه می‌تواند به یک Junior کمک کند این مهارت را به‌تدریج توسعه دهد.

🏢 چرا بعضی شرکت‌ها Exploratory Testing را جدی نمی‌گیرند؟

نگاه منفی به Exploratory Testing همیشه از ناآگاهی ناشی نمی‌شود. گاهی این دیدگاه به مشکلات واقعی در فرآیندهای سازمانی یا تجربه‌های ناموفق قبلی برمی‌گردد.

📊 ۱. KPIهای نامناسب

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

در چنین سازمانی ممکن است QA به‌جای تمرکز روی ریسک، به سمت تولید خروجی‌های قابل شمارش حرکت کند.

⏱️ ۲. فشار برای Release سریع

گاهی تیم واقعاً زمان کافی ندارد. در این شرایط، مدیر ممکن است تصور کند Exploratory Testing یک فعالیت اضافی است.

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

👥 ۳. کمبود تستر باتجربه

اگر تیم تجربه کافی در اجرای Exploratory Testing نداشته باشد، Session ممکن است واقعاً بی‌هدف و کم‌اثر شود.

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

📋 ۴. نیاز به مستندسازی و شواهد رسمی

در برخی پروژه‌ها، به‌خصوص محیط‌هایی که الزامات قانونی، قراردادی یا ممیزی وجود دارد، تیم باید بتواند نشان دهد دقیقاً چه تست‌هایی اجرا شده‌اند.

در این شرایط، Exploratory Testing می‌تواند ارزشمند باشد، اما معمولاً به‌عنوان مکمل تست‌های مستند و قابل ردیابی استفاده می‌شود.

🧠 ۵. سوءبرداشت درباره معنای Exploratory Testing

اگر مدیر یا اعضای تیم، Exploratory Testing را فقط «کلیک کردن تصادفی» بدانند، طبیعی است که ارزش آن را پایین ارزیابی کنند.

یکی از وظایف QA حرفه‌ای این است که هدف، ریسک، روش اجرا و خروجی Session را به‌صورت شفاف توضیح دهد.

🎯 نتیجه مهم:

اگر یک سازمان Exploratory Testing را بدون هدف، بدون مدیریت زمان و بدون گزارش‌پذیری اجرا کند و سپس از نتیجه ناراضی باشد، ممکن است مشکل اصلی از روش اجرا باشد، نه از خود رویکرد.

💰 هزینه واقعی وقتی مشتری اولین کسی باشد که Bug را پیدا می‌کند

گاهی گفته می‌شود:

«اگر Bugی وجود داشته باشد، مشتری آن را گزارش می‌کند.»

این جمله یک نکته مهم را نادیده می‌گیرد:

پیدا شدن Bug توسط مشتری معمولاً فقط هزینه اصلاح کد را به همراه ندارد.

وقتی یک نقص در محیط واقعی کشف می‌شود، ممکن است چند تیم و چند فرآیند هم‌زمان درگیر شوند.

• 📞 تیم Support باید به مشتری پاسخ دهد.
• 📝 Issue باید ثبت و تحلیل شود.
• 👨‍💻 تیم Development باید مشکل را بررسی و اصلاح کند.
• 🧪 تیم QA باید نسخه اصلاح‌شده را دوباره بررسی کند.
• 🚀 ممکن است Hotfix یا Release اضطراری لازم باشد.
• 📊 داده‌ها یا تراکنش‌های واقعی باید بررسی شوند.

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

🛒 مثال: Bug در فرآیند پرداخت فروشگاه اینترنتی

فرض کنید یک فروشگاه اینترنتی به دلیل یک Bug، هنگام استفاده هم‌زمان از کد تخفیف و کارت هدیه مبلغ نهایی را اشتباه محاسبه می‌کند.

اگر این مشکل توسط مشتریان در Production کشف شود، ممکن است نتیجه شامل موارد زیر باشد:

• ثبت سفارش‌های اشتباه
• درخواست‌های بازگشت وجه
• افزایش حجم تماس‌های Support
• درگیر شدن تیم مالی
• توقف موقت انتشار قابلیت‌های جدید
• نیاز به Hotfix و بررسی مجدد

اگر همان رفتار قبل از انتشار و در یک Session هدفمند کشف شود، احتمالاً فرآیند اصلاح و مدیریت آن ساده‌تر خواهد بود.

⚖️ آیا باید همه چیز را با Exploratory Testing تست کنیم؟

خیر.

هدف این نیست که برای هر تغییر کوچک ساعت‌ها تست اکتشافی انجام دهیم. یک تیم حرفه‌ای باید بین هزینه تست و ریسک شکست تعادل برقرار کند.

نوع قابلیت	ارزش احتمالی Exploratory Testing
تغییر کوچک ظاهری و کم‌ریسک	🟢 معمولاً پایین
صفحه ورود کاربران	🟡 متوسط تا بالا
بازیابی رمز عبور	🟠 بالا
فرآیند پرداخت	🔴 بسیار بالا
محاسبه مبلغ سفارش	🚨 بسیار بالا
انتقال وجه یا عملیات مالی حساس	🚨 بسیار بالا

هرچه ریسک یک قابلیت بیشتر باشد، سرمایه‌گذاری هدفمند روی روش‌های مختلف تست، از جمله Exploratory Testing، اهمیت بیشتری پیدا می‌کند.

💡 به خاطر بسپارید:

هدف QA حرفه‌ای این نیست که همه Bugها را پیدا کند؛ هدف این است که احتمال رسیدن ریسک‌های مهم و پرهزینه به دست مشتری را تا حد ممکن کاهش دهد.

🧠 نگاه یک QA Senior

یک QA حرفه‌ای معمولاً سؤال نمی‌کند:

«چقدر زمان برای تست داریم؟»

او علاوه بر آن می‌پرسد:

«اگر این قسمت را کمتر تست کنیم، چه ریسکی را می‌پذیریم؟»

این تغییر زاویه نگاه، QA را از اجرای صرف تست به سمت مدیریت ریسک محصول هدایت می‌کند.

📌 خلاصه این بخش

• ✅ Exploratory Testing می‌تواند در کنار Test Case و Automation Testing ارزش بیشتری ایجاد کند.
• ✅ مشتری نباید به‌عنوان آخرین مرحله کشف Bugهای مهم در نظر گرفته شود.
• ✅ دیدگاه‌های منفی درباره Exploratory Testing گاهی نتیجه اجرای ضعیف یا KPIهای نامناسب هستند.
• ✅ هزینه یک Bug در Production ممکن است فراتر از هزینه اصلاح کد باشد.
• ✅ بهترین تصمیم، انتخاب روش‌های تست بر اساس ریسک و اهمیت Feature است.

🔄 Exploratory Testing در Agile و Scrum؛ چرا این روش در تیم‌های مدرن محبوب است؟

اگر چند سال قبل وارد یک تیم توسعه نرم‌افزار می‌شدید، ممکن بود فرآیند تست چیزی شبیه این باشد: ابتدا نیازمندی‌ها مشخص می‌شدند، سپس Test Caseها طراحی می‌شدند، بعد توسعه انجام می‌شد و در نهایت تیم QA مجموعه تست‌ها را اجرا می‌کرد.

این مدل همچنان در بسیاری از پروژه‌ها کاربرد دارد؛ اما در تیم‌هایی که با Agile و Scrum کار می‌کنند، تغییرات سریع‌تر هستند و تیم باید در بازه‌های کوتاه بازخورد دریافت کند.

در چنین محیطی، Exploratory Testing می‌تواند در کنار Test Caseها و Automation Testing به تیم کمک کند تا ریسک‌های جدید و رفتارهای پیش‌بینی‌نشده را سریع‌تر بررسی کند.

⚡ تغییرات سریع، نیازمند بازخورد سریع

در Agile، یک Feature ممکن است در یک Sprint کوتاه توسعه پیدا کند، چند بار تغییر کند و سپس آماده Release شود. در چنین شرایطی، همیشه منطقی نیست که برای هر تغییر کوچک یک مجموعه بسیار بزرگ از Test Caseها طراحی و بازنویسی شود.

یک Session هدفمند Exploratory Testing می‌تواند به QA اجازه دهد در زمان محدود، مهم‌ترین ریسک‌های Feature را بررسی کند و بازخورد سریع‌تری به تیم بدهد.

🤝 کیفیت، مسئولیت کل تیم است

در Agile، کیفیت نباید فقط مسئولیت یک نقش خاص باشد. Developer، QA، Product Owner و سایر اعضای تیم، هرکدام از زاویه‌ای متفاوت به کیفیت محصول کمک می‌کنند.

به همین دلیل، Exploratory Testing نیز لزوماً نباید همیشه به‌صورت یک فعالیت کاملاً جدا از تیم انجام شود. در برخی تیم‌ها، اعضای مختلف می‌توانند در بررسی یک Feature مشارکت کنند و از زاویه دید خود ریسک‌های متفاوتی را آشکار کنند.

برای مثال، Developer ممکن است روی خطاهای فنی تمرکز کند، QA روی سناریوهای مرزی و ریسک‌ها تمرکز داشته باشد و Product Owner رفتار سیستم را از دید کاربر و نیاز کسب‌وکار بررسی کند.

🎯 چرا Exploratory Testing با Agile هماهنگ است؟

✅ سازگاری با تغییرات

در Agile، نیازمندی‌ها و طراحی Featureها ممکن است در طول توسعه تغییر کنند. Exploratory Testing نیز رویکردی انعطاف‌پذیر است و تستر می‌تواند بر اساس اطلاعات جدید، مسیر تست را تغییر دهد.

✅ بازخورد سریع

تستر می‌تواند پس از آماده شدن یک Feature، بررسی ریسک‌های اصلی را آغاز کند و بدون وابستگی کامل به یک مجموعه ثابت از سناریوها، بازخورد سریع‌تری به تیم بدهد.

✅ تمرکز بر ریسک

زمان در Sprint محدود است و تیم باید تصمیم بگیرد کدام بخش‌ها بیشترین اهمیت را دارند. Exploratory Testing می‌تواند Sessionها را روی قابلیت‌هایی متمرکز کند که از نظر کسب‌وکار یا فنی ریسک بالاتری دارند.

✅ یادگیری مداوم

Agile بر یادگیری و بهبود مستمر تأکید دارد. در Exploratory Testing نیز هر مشاهده می‌تواند به یک سؤال جدید منجر شود و هر سؤال می‌تواند اطلاعات تازه‌ای درباره محصول ایجاد کند.

🛠️ نقش Exploratory Testing در چرخه یک Sprint

Exploratory Testing می‌تواند در نقاط مختلف چرخه توسعه و تحویل محصول به کار گرفته شود.

• پس از آماده شدن یک Feature: برای کشف ریسک‌های اولیه و رفتارهای پیش‌بینی‌نشده.
• قبل از Sprint Review: برای بررسی Feature از زاویه دید کاربر و پیدا کردن مشکلاتی که ممکن است در تست‌های معمول دیده نشده باشند.
• قبل از Release: برای انجام یک بررسی هدفمند روی قسمت‌های پرریسک و مهم محصول.
• پس از رفع یک Bug مهم: برای بررسی اثرات جانبی اصلاح انجام‌شده و پیدا کردن مشکلات احتمالی مرتبط.

🧪 مثال: Exploratory Testing در یک Sprint

فرض کنید در Sprint جاری، قابلیت «پرداخت با کیف پول» به یک فروشگاه اینترنتی اضافه شده است.

Acceptance Criteria تأیید شده‌اند، Test Caseهای اصلی Pass شده‌اند و تست‌های خودکار نیز بدون خطا اجرا شده‌اند.

اما یک QA حرفه‌ای ممکن است هنوز این سؤال‌ها را مطرح کند:

• اگر موجودی کیف پول دقیقاً برابر مبلغ سفارش باشد چه؟
• اگر هنگام پرداخت اینترنت قطع شود چه؟
• اگر هم‌زمان از کیف پول و کد تخفیف استفاده شود چه؟
• اگر کاربر در دو دستگاه مختلف وارد حساب شده باشد چه؟
• اگر مبلغ سفارش پس از شروع فرآیند پرداخت تغییر کند چه؟
• اگر کاربر چند بار روی دکمه پرداخت کلیک کند چه؟

این سؤال‌ها می‌توانند مسیر یک Session اکتشافی را شکل دهند و به کشف ریسک‌هایی منجر شوند که در تست‌های ساختاریافته اولیه پوشش داده نشده‌اند.

💡 نکته حرفه‌ای: Agile بودن به معنی حذف تست‌های ساختاریافته نیست. سرعت توسعه باید با بازخورد سریع، مدیریت ریسک و استفاده هوشمندانه از روش‌های مختلف تست همراه شود.

🚫 یک تصور اشتباه

«چون Agile سریع است، دیگر نیازی به Exploratory Testing نداریم.»

✅ واقعیت

هرچه سرعت تغییرات بیشتر باشد، احتمال ایجاد رفتارهای جدید و پیش‌بینی‌نشده نیز می‌تواند بیشتر شود. Exploratory Testing می‌تواند به تیم کمک کند تا در کنار Automation و Test Caseها، سریع‌تر به کشف ریسک‌های ناشناخته بپردازد.

📌 خلاصه این بخش

• ✅ Agile و Scrum بر تغییرات سریع و بازخورد مداوم تأکید دارند.
• ✅ Exploratory Testing به دلیل انعطاف‌پذیری، با این محیط‌ها سازگاری خوبی دارد.
• ✅ این روش می‌تواند مکمل Test Caseها و Automation Testing باشد.
• ✅ هدف، انتخاب یک روش به‌عنوان برنده نیست؛ هدف، استفاده ترکیبی از روش‌ها برای کاهش ریسک محصول است.

⚖️ مزایا و محدودیت‌های Exploratory Testing؛ چه زمانی بهترین انتخاب است؟

هیچ روش تستی وجود ندارد که برای همه پروژه‌ها بهترین انتخاب باشد. قدرت واقعی یک QA Engineer در این است که بداند چه زمانی از هر رویکرد استفاده کند.

✅ مزایای Exploratory Testing

🚀 ۱. کشف ریسک‌هایی که در Test Caseها دیده نمی‌شوند

بزرگ‌ترین مزیت Exploratory Testing این است که تستر را به سناریوهای از پیش نوشته‌شده محدود نمی‌کند.

در پروژه‌های واقعی، بسیاری از مشکلات مهم دقیقاً در شرایطی رخ می‌دهند که هنگام طراحی Test Caseها پیش‌بینی نشده‌اند؛ مانند ترکیب چند عملیات، رفتار غیرمنتظره کاربران یا شرایط خاص شبکه.

🧠 ۲. استفاده از تجربه و خلاقیت تستر

در Exploratory Testing، تجربه، تحلیل و شناخت محصول نقش مهمی دارند. یک QA باتجربه ممکن است با چند سؤال درست، ریسک‌هایی را پیدا کند که اجرای Test Caseهای تکراری به‌تنهایی آن‌ها را آشکار نمی‌کند.

⚡ ۳. مناسب برای قابلیت‌های جدید یا در حال تغییر

در ابتدای توسعه یک Feature، ممکن است مستندات کامل نباشند و سیستم به‌سرعت تغییر کند. در چنین شرایطی، Exploratory Testing می‌تواند به تیم کمک کند هم‌زمان با تکامل محصول، ریسک‌ها را بررسی کند.

🔍 ۴. شناخت بهتر محصول

گاهی خروجی اصلی یک Session، پیدا کردن Bug نیست؛ بلکه شناخت بهتر رفتار سیستم است. این شناخت می‌تواند بعداً به طراحی Test Caseهای بهتر، اولویت‌بندی ریسک‌ها و تصمیم‌گیری برای Automation کمک کند.

🤝 ۵. تقویت همکاری بین اعضای تیم

وقتی نتایج یک Session با Developerها، Product Ownerها یا سایر اعضای تیم به اشتراک گذاشته می‌شود، درک مشترک تیم از رفتار واقعی محصول افزایش پیدا می‌کند.

⚠️ محدودیت‌های Exploratory Testing

📋 ۱. پوشش تست به‌اندازه Test Caseهای ساختاریافته قابل اندازه‌گیری نیست

وقتی Test Caseهای مشخصی دارید، به‌راحتی می‌توانید تعداد تست‌های اجراشده و وضعیت Pass یا Fail را گزارش کنید. در Exploratory Testing، اندازه‌گیری پوشش به شکل دیگری انجام می‌شود و معمولاً نیازمند ثبت دقیق محدوده، Session و یافته‌ها است.

👤 ۲. کیفیت نتایج به مهارت تستر وابسته است

دو QA ممکن است یک Session با هدف مشابه اجرا کنند اما خروجی متفاوتی داشته باشند؛ زیرا تجربه، دانش دامنه کسب‌وکار و توانایی تحلیل آن‌ها متفاوت است.

⏱️ ۳. برای تست‌های تکراری به‌تنهایی مناسب نیست

اگر قبل از هر Release باید یک مجموعه ثابت از سناریوها را بارها اجرا کنید، Scripted Testing و Automation معمولاً انتخاب‌های مناسب‌تری هستند.

📝 ۴. بدون مستندسازی، ارزش Session کاهش پیدا می‌کند

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

بهتر است حداقل هدف، Scope، مدت زمان، یافته‌ها، Bugها و موضوعات باقی‌مانده ثبت شوند.

🧭 چه زمانی Exploratory Testing بهترین انتخاب است؟

وضعیت پروژه	میزان تناسب با Exploratory Testing	دلیل
توسعه یک Feature جدید	✅ بالا	رفتارهای ناشناخته و ریسک‌های جدید
رفع یک Bug پیچیده	✅ بالا	بررسی اثرات جانبی و مسیرهای مرتبط
نسخه Release Candidate	✅ مناسب	بررسی ریسک‌های نهایی قبل از انتشار
Regression تکراری	⚠️ به‌تنهایی کافی نیست	Test Case و Automation معمولاً ارزش بیشتری دارند
قابلیت حساس مالی یا امنیتی	✅ بالا	بررسی سناریوهای غیرمنتظره اهمیت زیادی دارد
تغییر کوچک و کم‌ریسک در UI	🟡 بسته به ریسک	ممکن است تست هدفمند ساده کافی باشد

🚫 چه زمانی Exploratory Testing انتخاب مناسبی نیست؟

Exploratory Testing قدرتمند است، اما قرار نیست جای همه روش‌های تست را بگیرد.

🔁 زمانی که باید یک سناریوی ثابت را بارها اجرا کنید

اگر قبل از هر Release باید Login، ثبت سفارش، پرداخت و Logout را بارها و با الگوی ثابت بررسی کنید، Scripted Testing و Automation معمولاً انتخاب‌های منطقی‌تری هستند.

📜 زمانی که الزامات قانونی و ممیزی اهمیت زیادی دارند

در برخی صنایع و پروژه‌ها، سازمان باید شواهد مشخصی از اجرای تست‌ها ارائه دهد؛ از جمله اینکه چه چیزی تست شده، چه نتیجه‌ای داشته و چه کسی آن را اجرا کرده است.

در چنین شرایطی، Exploratory Testing می‌تواند مکمل ارزشمندی باشد، اما معمولاً به‌تنهایی برای پاسخ‌گویی به الزامات مستندسازی کافی نیست.

🤖 زمانی که هدف اجرای سریع تست‌های تکراری است

اگر تیم باید در هر Build یا Release در مدت کوتاهی سلامت بخش‌های اصلی سیستم را بررسی کند، Smoke Testing، Regression Testing و Automation معمولاً نقش اصلی را دارند.

👶 زمانی که تیم هنوز شناخت کافی از محصول ندارد

Exploratory Testing مؤثر به شناخت محصول و دامنه کسب‌وکار نیاز دارد. برای یک QA تازه‌وارد، مطالعه مستندات، اجرای Test Caseهای موجود و آشنایی تدریجی با سیستم می‌تواند نقطه شروع مناسبی باشد.

⚠️ زمانی که تیم می‌خواهد Exploratory Testing را جایگزین همه روش‌ها کند

این تصمیم معمولاً منطقی نیست. همان‌طور که کنار گذاشتن Exploratory Testing می‌تواند شکاف‌هایی ایجاد کند، حذف Test Caseها و Automation نیز ممکن است تکرارپذیری و پوشش سناریوهای شناخته‌شده را کاهش دهد.

🧭 یک قانون ساده برای تصمیم‌گیری

برای انتخاب روش مناسب، این سؤال را از خودتان بپرسید:

آیا هدف من بررسی چیزی است که از قبل می‌دانم، یا کشف چیزی است که هنوز نمی‌دانم؟

اگر هدف شما بررسی سناریوهای شناخته‌شده و تکرارشونده است، احتمالاً Scripted Testing یا Automation ارزش بیشتری ایجاد می‌کند.

اگر هدف شما کشف رفتارهای ناشناخته، بررسی ریسک‌های جدید و پیدا کردن سناریوهایی است که هنوز در Test Caseها ثبت نشده‌اند، Exploratory Testing می‌تواند انتخاب بسیار مناسبی باشد.

⚔️ Exploratory Testing چه تفاوتی با روش‌های دیگر تست دارد؟

یکی از دلایل سردرگمی بسیاری از افراد این است که مفاهیم مختلف تست نرم‌افزار را با یکدیگر اشتباه می‌گیرند.

برای مثال، گاهی Exploratory Testing با Ad-hoc Testing یکی دانسته می‌شود یا تصور می‌شود اجرای Exploratory Testing یعنی دیگر نیازی به Scripted Testing وجود ندارد.

در حالی که هر یک از این رویکردها هدف و کاربرد خاص خود را دارند.

🔄 Exploratory Testing در برابر Scripted Testing

در Scripted Testing، تستر معمولاً بر اساس Test Caseها یا سناریوهای از پیش طراحی‌شده عمل می‌کند و مراحل اجرا و نتیجه مورد انتظار مشخص هستند.

در Exploratory Testing، تستر در طول Session بر اساس مشاهدات، اطلاعات جدید و فرضیه‌های شکل‌گرفته، مسیر تست را تغییر می‌دهد.

ویژگی	Scripted Testing	Exploratory Testing
سناریوهای از پیش تعریف‌شده	✅ معمولاً بله	⚠️ معمولاً هدف یا Charter وجود دارد
انعطاف‌پذیری	🟡 کمتر	✅ بیشتر
تکرارپذیری	✅ بالا	🟡 وابسته به مستندسازی و رویکرد Session
مناسب برای Regression تکراری	✅ بسیار مناسب	⚠️ معمولاً به‌تنهایی کافی نیست
کشف رفتارهای ناشناخته	🟡 محدودتر	✅ مناسب‌تر
وابستگی به تجربه تستر	🟡 کمتر	✅ بیشتر

نتیجه: این دو روش رقیب یکدیگر نیستند. یک تیم حرفه‌ای می‌تواند از Scripted Testing برای پوشش سناریوهای شناخته‌شده و از Exploratory Testing برای کشف ریسک‌ها و رفتارهای ناشناخته استفاده کند.

🎲 Exploratory Testing در برابر Ad-hoc Testing

این دو مفهوم بیشتر از هر چیز دیگری با یکدیگر اشتباه گرفته می‌شوند، زیرا هر دو الزاماً به Test Caseهای دقیق و از پیش نوشته‌شده وابسته نیستند.

Ad-hoc Testing

در Ad-hoc Testing، فعالیت تست معمولاً بدون یک ساختار رسمی و جزئیات مستندشده انجام می‌شود و ممکن است هدف آن بررسی سریع یک قابلیت یا جست‌وجوی یک مشکل احتمالی باشد.

این روش لزوماً فرآیند مشخصی برای یادگیری، فرضیه‌سازی، ثبت یافته‌ها و تغییر آگاهانه مسیر تست ندارد.

Exploratory Testing

در یک Session حرفه‌ای Exploratory Testing، معمولاً عناصر ساختاریافته‌ای مانند موارد زیر وجود دارند:

• 🎯 هدف یا Charter مشخص
• ⏱️ Time Box یا بازه زمانی مشخص
• 📍 Scope یا محدوده تست
• 📝 ثبت مشاهدات و یافته‌ها
• 🧠 تحلیل نتایج و تصمیم‌گیری بر اساس شواهد

بنابراین ممکن است یک Session Exploratory از بیرون شبیه تست آزادانه به نظر برسد، اما تفاوت اصلی در هدفمندی، یادگیری و تصمیم‌گیری آگاهانه است.

📋 Exploratory Testing و Session-Based Test Management

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

Session-Based Test Management (SBTM) رویکردی برای سازمان‌دهی، مدیریت و گزارش‌دهی فعالیت‌های تست در قالب Sessionهای مشخص است که می‌تواند برای ساختارمند کردن Exploratory Testing استفاده شود.

در این رویکرد، معمولاً مواردی مانند هدف، مدت زمان، فعالیت‌ها، یافته‌ها و نتیجه Session ثبت می‌شوند.

به زبان ساده: Exploratory Testing به شما می‌گوید چگونه تست کنید و Session-Based Test Management کمک می‌کند این فعالیت را ساختارمند و قابل گزارش کنید.

🧪 یک مثال ساده برای درک تفاوت‌ها

فرض کنید سه QA قرار است قابلیت «ثبت‌نام کاربر» را بررسی کنند.

👨‍💻 QA اول؛ Scripted Testing

او Test Caseهای موجود را به ترتیب اجرا می‌کند و نتیجه هر مورد را با Expected Result مقایسه می‌کند.

👩‍💻 QA دوم؛ Ad-hoc Testing

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

🧑‍💻 QA سوم؛ Exploratory Testing

او ابتدا هدف Session را مشخص می‌کند، Scope را تعیین می‌کند، بر اساس شناخت محصول فرضیه می‌سازد، رفتار سیستم را تحلیل می‌کند و بر اساس یافته‌های جدید مسیر تست را تغییر می‌دهد.

در پایان، علاوه بر Bug Report ممکن است پیشنهادهایی برای بهبود Test Caseها، افزایش پوشش تست و Automation ارائه کند.

🚫 اشتباه رایج

«ما هر از گاهی بدون Test Case تست می‌کنیم؛ پس Exploratory Testing انجام می‌دهیم.»

نه لزوماً.

اگر فعالیت تست بدون هدف، بدون تحلیل، بدون یادگیری و بدون ثبت نتایج انجام شود، بیشتر به یک فعالیت Ad-hoc شباهت دارد.

💡 نکته حرفه‌ای: تفاوت اصلی Exploratory Testing با سایر روش‌ها در «نبود Test Case» نیست؛ بلکه در یادگیری مستمر، فرضیه‌سازی و تصمیم‌گیری آگاهانه در طول اجرای تست است.

📌 خلاصه این بخش

• ✅ Agile و Scrum محیط مناسبی برای استفاده هدفمند از Exploratory Testing ایجاد می‌کنند.
• ✅ Exploratory Testing مزایای زیادی برای کشف ریسک دارد، اما محدودیت‌های خودش را نیز دارد.
• ✅ برای تست‌های تکراری و قابل اندازه‌گیری، Scripted Testing و Automation معمولاً مناسب‌تر هستند.
• ✅ Ad-hoc Testing با Exploratory Testing یکی نیست؛ هدفمندی و یادگیری مداوم تفاوت مهمی ایجاد می‌کنند.
• ✅ Session-Based Test Management می‌تواند Exploratory Testing را ساختارمندتر و قابل گزارش‌تر کند.
• ✅ بهترین تیم‌ها معمولاً به‌جای انتخاب یک روش، ترکیبی از روش‌های تست را بر اساس ریسک و نیاز پروژه به کار می‌گیرند.

“

🧩 انواع و رویکردهای رایج در Exploratory Testing

وقتی درباره انواع Exploratory Testing صحبت می‌کنیم، بهتر است یک نکته را در نظر داشته باشیم: این دسته‌بندی‌ها در همه منابع به‌عنوان «انواع رسمی و کاملاً مستقل» تعریف نشده‌اند. در عمل، تیم‌های QA از رویکردهای مختلفی برای هدایت و ساختاردهی فعالیت‌های اکتشافی استفاده می‌کنند.

بنابراین بهتر است این موارد را بیشتر به‌عنوان رویکردها و الگوهای هدایت Exploratory Testing در نظر بگیریم، نه چند روش کاملاً جدا از یکدیگر.

🌀 ۱. Freestyle Exploratory Testing

در این رویکرد، تستر آزادی بیشتری برای کشف سیستم دارد و از مجموعه‌ای از Test Caseهای دقیق و از پیش نوشته‌شده پیروی نمی‌کند.

ممکن است فقط یک هدف کلی یا محدوده مشخص وجود داشته باشد و تستر در طول Session، بر اساس مشاهده‌ها و یافته‌های خود مسیر تست را انتخاب کند.

این رویکرد می‌تواند برای شناخت اولیه یک محصول، بررسی سریع یک Feature یا زمانی که اطلاعات اولیه درباره سیستم محدود است مفید باشد.

⚠️ نکته مهم: Freestyle به معنی بی‌هدف بودن نیست. حتی در یک Session آزاد، داشتن یک هدف کلی و ثبت یافته‌ها می‌تواند کیفیت فعالیت را به شکل قابل توجهی افزایش دهد.

🎯 ۲. Scenario-Based Exploratory Testing

در این رویکرد، تستر به‌جای طراحی مجموعه‌ای از Test Caseهای جزئی، یک سناریوی واقعی یا یک مسیر کاربری را دنبال می‌کند.

برای مثال، به‌جای اینکه فقط چند Test Case مربوط به خرید را اجرا کنیم، می‌توانیم مسیر یک کاربر واقعی را بررسی کنیم:

«من یک کاربر جدید هستم، وارد سایت می‌شوم، محصولی پیدا می‌کنم، آن را به سبد خرید اضافه می‌کنم، کد تخفیف وارد می‌کنم و در نهایت تلاش می‌کنم سفارش را پرداخت کنم.»

در طول این مسیر، هر رفتار غیرمنتظره یا سؤال جدید می‌تواند باعث تغییر مسیر Session شود.

این رویکرد برای بررسی End-to-End User Journey و کشف مشکلاتی که فقط از تعامل چند قابلیت با یکدیگر ایجاد می‌شوند، بسیار مفید است.

🧠 ۳. Strategy-Based Exploratory Testing

در این رویکرد، تستر یک یا چند استراتژی مشخص را برای هدایت Session انتخاب می‌کند.

برای مثال، ممکن است تصمیم بگیرد یک Feature را از زاویه‌های زیر بررسی کند:

• ورودی‌های نامعتبر
• مقادیر مرزی
• رفتار کاربران عجول
• خطاهای شبکه
• تغییر وضعیت Session
• تعامل هم‌زمان چند کاربر
• تجربه کاربری
• ریسک‌های امنیتی

این رویکرد کمک می‌کند تستر به‌جای حرکت تصادفی در سیستم، یک زاویه دید مشخص برای Session داشته باشد.

⚠️ ۴. Risk-Based Exploratory Testing

در Risk-Based Exploratory Testing، زمان و انرژی تستر روی بخش‌هایی متمرکز می‌شود که بیشترین ریسک را برای کاربر یا کسب‌وکار دارند.

برای مثال، در یک فروشگاه اینترنتی ممکن است اهمیت قابلیت‌ها به شکل زیر ارزیابی شود:

قابلیت	سطح ریسک	تمرکز Exploratory Testing
تغییر کوچک ظاهری	🟢 پایین	کم
ثبت‌نام کاربر	🟡 متوسط	متوسط
بازیابی رمز عبور	🟠 بالا	زیاد
پرداخت آنلاین	🔴 بسیار بالا	بسیار زیاد
محاسبه مبلغ سفارش	🚨 بحرانی	بسیار زیاد

در این مدل، هدف این نیست که همه بخش‌های سیستم به یک اندازه تست شوند؛ بلکه هدف این است که محدودیت زمان را روی مهم‌ترین ریسک‌ها سرمایه‌گذاری کنیم.

📋 ۵. Session-Based Exploratory Testing

در این رویکرد، فعالیت Exploratory Testing در قالب Sessionهای مشخص و زمان‌بندی‌شده انجام می‌شود.

هر Session معمولاً هدف مشخص، Scope، بازه زمانی و خروجی قابل گزارش دارد.

این رویکرد برای تیم‌هایی مناسب است که می‌خواهند انعطاف Exploratory Testing را حفظ کنند، اما در عین حال فعالیت تست برای تیم و مدیریت قابل مشاهده و قابل پیگیری باشد.

💡 نکته حرفه‌ای: این رویکردها الزاماً از یکدیگر جدا نیستند. برای مثال، یک Session می‌تواند هم‌زمان Scenario-Based و Risk-Based باشد و در قالب Session-Based Test Management مدیریت شود.

📌 خلاصه این بخش

• ✅ Exploratory Testing می‌تواند با رویکردهای مختلف هدایت شود.
• ✅ Freestyle آزادی بیشتری برای کشف ایجاد می‌کند.
• ✅ Scenario-Based روی مسیرهای واقعی کاربران تمرکز دارد.
• ✅ Strategy-Based یک زاویه دید مشخص برای Session ایجاد می‌کند.
• ✅ Risk-Based زمان را روی مهم‌ترین ریسک‌های محصول متمرکز می‌کند.
• ✅ Session-Based به ساختارمند شدن و گزارش‌پذیری فعالیت کمک می‌کند.

📋 Session-Based Exploratory Testing چیست؟

یکی از انتقادهای رایج به Exploratory Testing این است که مدیریت نمی‌تواند به‌راحتی متوجه شود تستر دقیقاً چه کاری انجام داده و خروجی Session چه بوده است.

این نگرانی زمانی جدی‌تر می‌شود که Exploratory Testing بدون هدف، بدون زمان‌بندی و بدون ثبت یافته‌ها اجرا شود.

یکی از راه‌های ساختارمند کردن این فعالیت، استفاده از Session-Based Test Management است.

در این رویکرد، تست اکتشافی همچنان انعطاف‌پذیر باقی می‌ماند، اما در قالب Sessionهای مشخص انجام می‌شود؛ به‌طوری که بتوان هدف، مدت زمان، فعالیت‌ها و یافته‌ها را گزارش کرد.

⏱️ Session چیست؟

Session یک بازه زمانی مشخص است که تستر در آن، روی یک هدف یا محدوده معین تمرکز می‌کند.

برای مثال:

هدف Session: کشف ریسک‌های فرآیند Checkout در شرایط خطا

مدت Session: ۶۰ دقیقه

Scope: سبد خرید، اعمال تخفیف و پرداخت

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

📝 Session Charter چیست؟

Session Charter یک توضیح کوتاه و هدفمند است که مشخص می‌کند تستر قرار است در یک Session چه چیزی را بررسی کند.

یک Charter خوب به تستر کمک می‌کند بداند:

• 🎯 روی چه چیزی تمرکز کند.
• 📍 محدوده تست کجاست.
• ⚠️ چه ریسکی اهمیت بیشتری دارد.
• ⏱️ Session چه مدت ادامه دارد.

🧪 نمونه Session Charter

عنوان	بررسی فرآیند Checkout
هدف	کشف خطاهای مربوط به محاسبه مبلغ نهایی و پرداخت
Scope	Cart، Discount، Payment
تمرکز	رفتارهای غیرعادی، قطع اینترنت و عملیات تکراری
مدت زمان	۶۰ دقیقه
محیط	Chrome / Desktop / Staging

این Charter به تستر آزادی می‌دهد که مسیر تست را بر اساس یافته‌های جدید تغییر دهد، اما در عین حال مشخص می‌کند Session قرار است به چه سؤال اصلی پاسخ دهد.

🔍 Session چگونه اجرا می‌شود؟

1. هدف و Charter مشخص می‌شود.
2. Scope و بازه زمانی Session تعیین می‌شود.
3. تستر فعالیت اکتشافی را آغاز می‌کند.
4. یافته‌ها، سؤال‌های جدید و Bugها ثبت می‌شوند.
5. در صورت کشف ریسک جدید، مسیر تست می‌تواند تغییر کند.
6. در پایان Session، نتایج مرور و خلاصه می‌شوند.

📊 پایان Session چه چیزی باید گزارش شود؟

یک گزارش ساده اما مفید می‌تواند شامل این موارد باشد:

• مدت زمان واقعی Session
• Scopeای که بررسی شد
• سناریوها یا مسیرهای مهمی که آزمایش شدند
• Bugهای کشف‌شده
• ریسک‌های شناسایی‌شده
• سؤال‌هایی که هنوز پاسخ داده نشده‌اند
• پیشنهاد برای تست‌های بعدی
• پیشنهاد برای Test Case یا Automation

💡 چرا Session-Based Testing می‌تواند برای مدیران مفید باشد؟

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

Session-Based Test Management کمک می‌کند Exploratory Testing از یک فعالیت مبهم به یک فعالیت قابل مشاهده‌تر تبدیل شود.

مدیر می‌تواند ببیند:

• چند Session انجام شده است.
• چه بخش‌هایی بررسی شده‌اند.
• چه ریسک‌هایی کشف شده‌اند.
• چه Bugهایی پیدا شده‌اند.
• چه موضوعاتی برای بررسی آینده باقی مانده‌اند.

این موضوع به معنی تبدیل Exploratory Testing به یک فعالیت صرفاً عددی نیست؛ بلکه کمک می‌کند ارزش کاری که انجام شده بهتر قابل مشاهده و توضیح باشد.

🧠 نگاه یک QA Senior: اگر قرار است درباره Exploratory Testing به مدیر گزارش بدهید، فقط نگویید «یک ساعت تست کردم». توضیح دهید چه ریسکی را بررسی کردید، چه چیزی یاد گرفتید، چه Bugهایی پیدا شدند و چه تصمیم‌هایی بر اساس یافته‌ها گرفته شد.

❌ باور اشتباه

«Session-Based Testing آزادی Exploratory Testing را از بین می‌برد.»

✅ واقعیت

Session-Based Testing قرار نیست مسیر تک‌تک کلیک‌ها را از قبل تعیین کند. هدف آن ایجاد یک چارچوب سبک برای تعریف هدف، مدیریت زمان و گزارش خروجی است؛ در حالی که تستر همچنان می‌تواند بر اساس کشف‌های جدید مسیر خود را تغییر دهد.

🚫 اشتباهات رایج در انجام Exploratory Testing

Exploratory Testing اگر درست اجرا شود می‌تواند بسیار ارزشمند باشد؛ اما اجرای ضعیف آن ممکن است همان انتقادهای رایجی را ایجاد کند که درباره این روش مطرح می‌شوند.

❌ اشتباه اول: شروع تست بدون هدف مشخص

باز کردن نرم‌افزار و حرکت از یک صفحه به صفحه دیگر، به‌تنهایی Exploratory Testing حرفه‌ای محسوب نمی‌شود.

اگر تستر نداند قرار است چه چیزی را یاد بگیرد یا چه ریسکی را بررسی کند، احتمال دارد Session به فعالیت‌های پراکنده تبدیل شود.

✅ به‌جای اینکه بگویید: «می‌خواهم Checkout را تست کنم.»

بهتر است بگویید: «می‌خواهم ریسک‌های محاسبه مبلغ نهایی و رفتار پرداخت را در شرایط غیرعادی بررسی کنم.»

❌ اشتباه دوم: تمرکز فقط روی پیدا کردن Bug

اگر ارزش یک Session فقط با تعداد Bugهای ثبت‌شده سنجیده شود، ممکن است تستر به‌جای ریسک‌های مهم، وقت خود را صرف مشکلات کم‌اهمیت کند.

یادگیری درباره محصول، کشف ریسک، شناسایی شکاف‌های Test Case و ایجاد ایده برای تست‌های بعدی نیز می‌توانند خروجی‌های مهم Session باشند.

❌ اشتباه سوم: تغییر مسیر بدون منطق

انعطاف‌پذیری یکی از نقاط قوت Exploratory Testing است؛ اما انعطاف‌پذیری با بی‌نظمی تفاوت دارد.

اگر هر بار که یک نکته جدید می‌بینید بدون ثبت علت و ارتباط آن با هدف Session مسیر را تغییر دهید، ممکن است در پایان ندانید چه چیزی را بررسی کرده‌اید.

تغییر مسیر بهتر است بر اساس مشاهده، ریسک یا فرضیه‌ای جدید باشد.

❌ اشتباه چهارم: ثبت نکردن مشاهدات

یکی از بزرگ‌ترین اشتباهات این است که تستر بعد از یک ساعت تست فقط بگوید:

«چند چیز را بررسی کردم و مشکلی ندیدم.»

این گزارش اطلاعات کمی برای تیم ایجاد می‌کند.

بهتر است حداقل موارد زیر ثبت شوند:

• چه چیزی بررسی شد؟
• چه فرضیه‌هایی آزمایش شدند؟
• چه رفتارهای غیرمنتظره‌ای مشاهده شد؟
• چه Bugهایی پیدا شدند؟
• چه سؤال‌های جدیدی ایجاد شد؟

❌ اشتباه پنجم: نادیده گرفتن ریسک‌های کسب‌وکار

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

برای مثال، یک مشکل کوچک در Alignment یک دکمه ممکن است اهمیت بسیار کمتری نسبت به یک خطای محاسبه مبلغ سفارش داشته باشد.

«اگر فقط یک ساعت برای تست این Feature داشته باشم، کجا بیشترین ارزش را ایجاد می‌کنم؟»

❌ اشتباه ششم: تصور اینکه هر رفتار عجیب یک Bug است

در طول Exploratory Testing ممکن است با رفتارهای غیرمنتظره‌ای مواجه شوید؛ اما هر رفتار غیرعادی الزاماً Bug نیست.

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

یک QA حرفه‌ای قبل از ثبت Bug از خودش می‌پرسد:

• آیا این رفتار واقعاً خلاف نیازمندی است؟
• آیا این رفتار از نظر کسب‌وکار قابل قبول است؟
• آیا ممکن است این رفتار یک محدودیت طراحی‌شده باشد؟

❌ اشتباه هفتم: نادیده گرفتن یافته‌های قبلی

اگر در Sessionهای قبلی یک الگوی مشخص از خطاها یا ریسک‌ها شناسایی شده است، نباید هر Session را کاملاً از صفر شروع کرد.

یافته‌های قبلی می‌توانند ورودی Sessionهای بعدی باشند و مسیرهای جدیدی برای تست ایجاد کنند.

❌ اشتباه هشتم: تبدیل Exploratory Testing به تست بدون محدودیت زمانی

ممکن است تستر پس از پیدا کردن یک مسیر جذاب، مدت زیادی روی همان بخش باقی بماند و قسمت‌های مهم دیگر را بررسی نکند.

استفاده از Time Box کمک می‌کند تمرکز حفظ شود و تستر بداند چه زمانی باید Session را جمع‌بندی کند یا مسیر دیگری را بررسی کند.

⭐ بهترین روش‌ها برای Exploratory Testing حرفه‌ای

هیچ فرمول واحدی وجود ندارد که کیفیت Exploratory Testing را در همه پروژه‌ها تضمین کند؛ اما چند Best Practice می‌تواند احتمال ایجاد ارزش واقعی را افزایش دهد.

⭐ ۱. همیشه با یک سؤال شروع کنید

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

«مهم‌ترین چیزی که می‌خواهم در این Session یاد بگیرم چیست؟»

⭐ ۲. بر اساس ریسک اولویت‌بندی کنید

زمان شما محدود است. بهتر است ابتدا روی بخش‌هایی تمرکز کنید که شکست آن‌ها بیشترین آسیب را به کاربر یا کسب‌وکار وارد می‌کند.

⭐ ۳. از Test Heuristicها استفاده کنید

Heuristicها می‌توانند برای تولید ایده‌های جدید تست مفید باشند.

برای مثال:

• چه اتفاقی می‌افتد اگر ورودی خالی باشد؟
• اگر ورودی بسیار بزرگ باشد چه؟
• اگر مقدار نامعتبر وارد شود چه؟
• اگر یک عملیات دوبار اجرا شود چه؟
• اگر عملیات در نیمه راه متوقف شود چه؟
• اگر دو عملیات هم‌زمان انجام شوند چه؟
• اگر Session منقضی شود چه؟

⭐ ۴. شرایط واقعی استفاده را شبیه‌سازی کنید

گاهی بهترین راه برای پیدا کردن Bug این است که سیستم را از زاویه کاربر واقعی بررسی کنید.

کاربر واقعی ممکن است عجله داشته باشد، اشتباه کند، اینترنت ناپایدار داشته باشد یا ترتیب غیرمنتظره‌ای از اقدامات را انجام دهد.

⭐ ۵. از Sessionهای کوتاه و متمرکز استفاده کنید

Sessionهای کوتاه‌تر و هدفمند معمولاً تمرکز و گزارش‌پذیری بهتری دارند.

برای مثال، به‌جای «تست کل فروشگاه»، یک Session با هدف «کشف ریسک‌های پرداخت در شرایط قطع اینترنت» تعریف کنید.

⭐ ۶. بعد از هر Bug سؤال‌های جدیدی بپرسید

یک Bug می‌تواند یک نشانه باشد، نه یک نقطه پایان.

اگر یک خطا پیدا کردید، بررسی کنید آیا الگوی مشابهی ممکن است در بخش‌های دیگر نیز وجود داشته باشد.

⭐ ۷. یافته‌ها را به Test Case تبدیل کنید

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

به این ترتیب، Exploratory Testing می‌تواند به بهبود مستمر Test Suite کمک کند.

⭐ ۸. سناریوهای ارزشمند را Automate کنید

همه چیز را نباید Automate کرد؛ اما سناریوهایی که تکرارپذیر، پایدار و مهم هستند ممکن است گزینه‌های مناسبی برای Automation باشند.

یک الگوی مفید می‌تواند این باشد:

Explore → Discover → Stabilize → Automate

ابتدا با Exploratory Testing چیزی را کشف می‌کنیم، سپس سناریوی ارزشمند را پایدار می‌کنیم و در صورت مناسب بودن، آن را به تست خودکار تبدیل می‌کنیم.

⭐ ۹. با اعضای تیم Pair کنید

گاهی دو نفر با دو زاویه دید متفاوت می‌توانند در یک Session نتایج بهتری از یک نفر به‌تنهایی ایجاد کنند.

برای مثال، QA و Developer یا QA و Product Owner می‌توانند در یک Session مشترک حضور داشته باشند.

⭐ ۱۰. از مستندسازی بیش از حد و کم‌مستندسازی هر دو پرهیز کنید

هدف مستندسازی این نیست که Exploratory Testing را به مجموعه‌ای از Test Caseهای ثابت تبدیل کنیم.

مستندات باید به اندازه‌ای باشند که تیم بداند چه چیزی بررسی شده، چه چیزی کشف شده و چه موضوعی نیاز به پیگیری دارد.

⭐ ۱۱. زمان را به شکل آگاهانه مدیریت کنید

Time Box به تستر اجازه می‌دهد بین عمق و گستردگی تست تعادل برقرار کند.

برای مثال، Sessionهای ۳۰، ۴۵ یا ۶۰ دقیقه‌ای را می‌توان بر اساس سطح ریسک و هدف تعیین کرد.

⭐ ۱۲. یافته‌ها را با تیم به اشتراک بگذارید

ارزش یک Session فقط در ذهن تستر باقی نمی‌ماند.

یافته‌ها باید در صورت نیاز با Developer، Product Owner، Business Analyst و سایر اعضای تیم به اشتراک گذاشته شوند.

⭐ ۱۳. از یافته‌ها برای بهبود محصول استفاده کنید

اگر در Sessionها به‌طور مداوم یک نوع مشکل مشاهده می‌شود، شاید مشکل فقط در یک Feature نباشد؛ ممکن است نشانه ضعف در طراحی، معماری، نیازمندی یا فرآیند توسعه باشد.

⭐ ۱۴. کیفیت Session را با تعداد Bug نسنجید

معیارهای مفیدتر می‌توانند شامل میزان پوشش ریسک، یافته‌های جدید، شکاف‌های شناسایی‌شده و میزان بهبود Test Suite باشند.

⭐ ۱۵. بعد از Session Retrospective انجام دهید

از خودتان بپرسید:

• چه چیزی خوب پیش رفت؟
• چه چیزی از دست رفت؟
• کدام ریسک‌ها هنوز بررسی نشده‌اند؟
• Session بعدی باید روی چه چیزی تمرکز کند؟

🧠 نگاه یک QA Senior

یک QA حرفه‌ای فقط تست را تمام نمی‌کند؛ از هر Session چیزی برای بهتر کردن Session بعدی یاد می‌گیرد.

📋 چک‌لیست سریع قبل از شروع Exploratory Testing

قبل از شروع یک Session، این سؤال‌ها را از خودتان بپرسید:

• ☐ هدف Session مشخص است؟
• ☐ Scope تست مشخص است؟
• ☐ مهم‌ترین ریسک Feature را می‌دانم؟
• ☐ زمان مشخصی برای Session در نظر گرفته‌ام؟
• ☐ محیط و داده‌های لازم آماده هستند؟
• ☐ وابستگی‌های مهم Feature را می‌شناسم؟
• ☐ آماده‌ام بر اساس یافته‌های جدید مسیر تست را تغییر دهم؟
• ☐ جایی برای ثبت مشاهدات و نتایج دارم؟

این چک‌لیست کوتاه کمک می‌کند فعالیت شما از یک تست آزاد و بدون جهت، به یک Session هدفمند تبدیل شود.

🎯 اگر فقط یک سؤال قبل از شروع Session از خودتان بپرسید:

«مهم‌ترین چیزی که می‌خواهم از این Session یاد بگیرم چیست؟»

📌 خلاصه این بخش

• ✅ Exploratory Testing می‌تواند با رویکردهای مختلف مانند Scenario-Based و Risk-Based هدایت شود.
• ✅ Session-Based Test Management به ساختارمند شدن فعالیت‌های اکتشافی کمک می‌کند.
• ✅ Session Charter هدف، Scope و تمرکز یک Session را مشخص می‌کند.
• ✅ یک Session خوب هم آزادی اکتشاف دارد و هم چارچوب و هدف روشن.
• ✅ ثبت یافته‌ها، مدیریت زمان و انتقال دانش، ارزش Exploratory Testing را بیشتر می‌کنند.

🛠️ ابزارهای مفید برای Exploratory Testing

Exploratory Testing ذاتاً به یک ابزار خاص وابسته نیست. حتی می‌توان یک Session را با یک مرورگر، یک ابزار ثبت یادداشت و یک سیستم مدیریت Bug اجرا کرد.

با این حال، ابزارهای مختلف می‌توانند بخش‌هایی از فرآیند مانند ثبت شواهد، بازتولید Bug، مدیریت Session و تحلیل رفتار سیستم را ساده‌تر کنند.

📝 ابزارهای مدیریت و ثبت نتایج

برای ثبت Charter، یادداشت‌ها، یافته‌ها و نتایج Session می‌توان از ابزارهایی مانند Jira، Azure DevOps، TestRail، qTest، Xray، Notion و Confluence استفاده کرد.

انتخاب ابزار مهم است، اما مهم‌تر از آن این است که اطلاعات Session برای تیم قابل دسترسی و قابل استفاده باشد.

🌐 ابزارهای Browser DevTools

برای Exploratory Testing در Web Applicationها، ابزارهای Developer Tools مرورگر می‌توانند بسیار مفید باشند.

• بررسی Network Requestها
• مشاهده Responseهای API
• بررسی Console Errorها
• بررسی Cookieها و Storage
• بررسی DOM و رفتار رابط کاربری
• بررسی Performance

🎥 ابزارهای Screenshot و Video

در زمان کشف یک Bug، Screenshot و Video می‌توانند بازتولید مشکل و ارتباط با تیم توسعه را ساده‌تر کنند.

بهتر است هنگام ثبت شواهد، اطلاعات حساس کاربران یا داده‌های محرمانه در تصویر یا ویدئو نمایش داده نشوند.

🤖 Automation در کنار Exploratory Testing

Automation و Exploratory Testing می‌توانند یکدیگر را تکمیل کنند.

برای مثال، تستر می‌تواند در یک Session اکتشافی یک سناریوی جدید را کشف کند و پس از مشخص شدن ارزش و پایداری آن، تصمیم بگیرد که آیا سناریو باید به یک Test Case پایدار یا تست خودکار تبدیل شود یا خیر.

ابزارهایی مانند Playwright و Selenium می‌توانند برای اجرای Automation سناریوهای تکراری و پایدار استفاده شوند و در کنار Exploratory Testing، یک استراتژی ترکیبی ایجاد کنند.

🔍 Playwright و شواهد اجرای تست

در پروژه‌هایی که از Playwright استفاده می‌شود، قابلیت‌هایی مانند Screenshot، Video و Trace می‌توانند برای بررسی شکست تست‌ها و تحلیل رفتار اجرای تست مفید باشند.

این قابلیت‌ها جای Exploratory Testing را نمی‌گیرند، اما می‌توانند به تیم کمک کنند نتایج Automation را بهتر تحلیل کند و سناریوهای ارزشمندتری برای بررسی‌های بعدی به دست آورد.

💡 انتخاب ابزار بر اساس نیاز، نه تعداد ابزارها

برای انجام Exploratory Testing لازم نیست ده‌ها ابزار در اختیار داشته باشید.

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

• 🌐 Browser DevTools برای مشاهده رفتار سیستم
• 📝 Jira یا ابزار مشابه برای ثبت یافته‌ها و Bugها
• 📋 Notion یا Confluence برای ثبت Charter و دانش Session
• 🎥 Screenshot و Video برای ثبت شواهد
• 🤖 Playwright یا Selenium برای Automation سناریوهای پایدار و تکراری

💡 نکته حرفه‌ای: ابزار خوب، تستر ضعیف را به تستر حرفه‌ای تبدیل نمی‌کند. مهم‌ترین ابزار Exploratory Testing همچنان ذهن تحلیلگر، دانش محصول و توانایی پرسیدن سؤال‌های درست است.

🤖 هوش مصنوعی و Exploratory Testing؛ آیا AI می‌تواند جای QA را بگیرد؟

با گسترش ابزارهای هوش مصنوعی، مدل‌های زبانی بزرگ و سیستم‌های Agentic، یک سؤال مهم برای بسیاری از QA Engineerها شکل گرفته است:

آیا با پیشرفت AI، Exploratory Testing و حتی نقش تستر نرم‌افزار از بین خواهد رفت؟

به نظر می‌رسد پاسخ دقیق‌تر این باشد که AI احتمالاً شکل انجام بخشی از فعالیت‌های QA را تغییر خواهد داد، اما لزوماً جایگزین کامل قضاوت و تحلیل انسانی نخواهد شد.

💡 AI چگونه می‌تواند به Exploratory Testing کمک کند؟

• تولید ایده‌های تست: پیشنهاد سناریوهای احتمالی و شرایط مرزی.
• پیشنهاد Heuristic: معرفی زاویه‌های جدید برای بررسی یک Feature.
• تحلیل یافته‌ها: خلاصه‌سازی یادداشت‌ها و دسته‌بندی مشکلات مشابه.
• تولید Test Data: کمک به تولید داده‌های متنوع و شرایط آزمایشی.
• کمک به Bug Reporting: ساخت پیش‌نویس ساختاریافته از یادداشت‌های اولیه تستر.
• پیشنهاد Automation: شناسایی سناریوهایی که ممکن است ارزش تبدیل شدن به تست خودکار داشته باشند.

🧠 AI به‌عنوان Thinking Partner

یک کاربرد جالب AI این است که تستر بتواند از آن به‌عنوان یک هم‌فکر استفاده کند.

برای مثال، QA می‌تواند توضیح یک Feature را در اختیار AI قرار دهد و بپرسد:

«اگر بخواهم این Feature را از نظر ریسک‌های پنهان بررسی کنم، چه سناریوهایی ممکن است از قلم افتاده باشند؟»

AI می‌تواند ایده‌هایی پیشنهاد دهد که تستر آن‌ها را بررسی یا رد کند.

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

🤖 Agentic AI و آینده Exploratory Testing

با توسعه سیستم‌های Agentic، می‌توان تصور کرد ابزارهایی در آینده بتوانند بر اساس یک هدف مشخص، چند مرحله را پشت سر هم انجام دهند و با نرم‌افزار و ابزارهای مختلف تعامل کنند.

برای مثال، یک Agent ممکن است هدفی مانند این دریافت کند:

«ریسک‌های فرآیند Checkout را بررسی کن و رفتارهای مشکوک را گزارش بده.»

سپس ممکن است مسیرهای مختلف را امتحان کند، شواهد جمع‌آوری کند و یافته‌های خود را در اختیار QA قرار دهد.

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

⚠️ چرا AI هنوز جای Exploratory Testing انسانی را کامل نمی‌گیرد؟

• 🧠 درک Context محصول
• 🎯 تشخیص ریسک واقعی کسب‌وکار
• 👤 فهم رفتار کاربران واقعی
• ⚖️ تصمیم‌گیری درباره اهمیت یک یافته
• 🔍 تشخیص اینکه یک رفتار واقعاً Bug است یا رفتار مورد انتظار
• 🤝 ارتباط با تیم و تبدیل یافته به تصمیم عملی

به همین دلیل، می‌توان آینده QA را بیشتر به سمت مدل Human + AI دید؛ جایی که AI بخشی از کارهای تحلیلی و تکراری را تقویت می‌کند و QA مسئول درک Context، ارزیابی ریسک و تصمیم‌گیری نهایی باقی می‌ماند.

🚨 نکته مهم درباره استفاده از AI در QA

اطلاعات حساس، داده‌های واقعی مشتریان، اطلاعات محرمانه کسب‌وکار و جزئیات امنیتی نباید بدون بررسی سیاست‌های سازمان و ملاحظات حریم خصوصی در اختیار ابزارهای AI قرار گیرند.

همچنین خروجی AI باید مانند خروجی یک همکار بررسی و اعتبارسنجی شود؛ نه اینکه بدون بررسی به‌عنوان حقیقت قطعی پذیرفته شود.

🎤 سؤالات مصاحبه Exploratory Testing؛ از Junior تا Senior

اگر برای موقعیت‌های شغلی QA آماده می‌شوید، احتمال دارد در مصاحبه درباره Exploratory Testing از شما سؤال شود.

🎤 سؤال ۱: Exploratory Testing چیست؟

پاسخ پیشنهادی: Exploratory Testing رویکردی است که در آن یادگیری سیستم، طراحی تست و اجرای تست به‌صورت هم‌زمان انجام می‌شوند. تستر بر اساس اطلاعات جدیدی که در طول Session به دست می‌آورد، مسیر تست را تغییر می‌دهد و تلاش می‌کند ریسک‌ها و رفتارهای پیش‌بینی‌نشده را کشف کند.

🎤 سؤال ۲: آیا Exploratory Testing همان Ad-hoc Testing است؟

پاسخ پیشنهادی: خیر. هر دو می‌توانند بدون Test Caseهای دقیق از پیش نوشته‌شده انجام شوند، اما Exploratory Testing معمولاً هدفمندتر است و بر یادگیری، مشاهده، فرضیه‌سازی و تصمیم‌گیری آگاهانه استوار است.

🎤 سؤال ۳: آیا Exploratory Testing جایگزین Automation Testing است؟

پاسخ پیشنهادی: خیر. Automation برای اجرای سریع و تکرارپذیر سناریوهای شناخته‌شده مناسب است، در حالی که Exploratory Testing برای کشف ریسک‌ها و رفتارهای ناشناخته ارزش بیشتری دارد. ترکیب این دو معمولاً نتیجه بهتری ایجاد می‌کند.

🎤 سؤال ۴: آیا Exploratory Testing بدون برنامه انجام می‌شود؟

پاسخ پیشنهادی: خیر. ممکن است Test Case دقیق و مرحله‌به‌مرحله وجود نداشته باشد، اما Session می‌تواند هدف، Charter، Scope، Time Box و روش گزارش‌دهی مشخص داشته باشد. آزادی در مسیر تست با بی‌برنامگی یکی نیست.

🎤 سؤال ۵: مهم‌ترین مزیت Exploratory Testing چیست؟

پاسخ پیشنهادی: یکی از مهم‌ترین مزایا، امکان کشف ریسک‌ها و رفتارهایی است که در سناریوهای از پیش تعریف‌شده پیش‌بینی نشده‌اند. همچنین تستر می‌تواند در طول Session بر اساس یافته‌های جدید مسیر تست را تغییر دهد.

🎤 سؤال ۶: مهم‌ترین محدودیت Exploratory Testing چیست؟

پاسخ پیشنهادی: کیفیت نتایج می‌تواند به تجربه تستر، شناخت محصول و کیفیت تصمیم‌گیری او وابسته باشد. همچنین پوشش تست به‌سادگی Test Caseهای ساختاریافته قابل اندازه‌گیری نیست.

🎤 سؤال ۷: Session-Based Testing چیست؟

پاسخ پیشنهادی: رویکردی برای ساختارمند کردن و مدیریت Sessionهای تست است که معمولاً شامل Charter، Scope، Time Box، ثبت فعالیت‌ها، یافته‌ها و گزارش نتایج می‌شود.

🎤 سؤال ۸: اگر در یک Session هیچ Bugی پیدا نکنید، آیا Session شکست خورده است؟

پاسخ پیشنهادی: خیر. اگر Session باعث شناخت بهتر سیستم، بررسی ریسک‌های مهم، کاهش عدم‌قطعیت یا تولید Test Ideaهای جدید شده باشد، همچنان می‌تواند ارزشمند باشد.

🎤 سؤال ۹: چگونه زمان Exploratory Testing را مدیریت می‌کنید؟

پاسخ پیشنهادی: از Time Box استفاده می‌کنم، مهم‌ترین ریسک‌ها را ابتدا بررسی می‌کنم و در طول Session یافته‌های جدید را بر اساس ریسک و ارزش اولویت‌بندی می‌کنم.

🎤 سؤال ۱۰: چگونه ارزش Exploratory Testing را به مدیر نشان می‌دهید؟

پاسخ پیشنهادی: به‌جای گزارش صرف تعداد ساعت تست، هدف Session، ریسک‌های بررسی‌شده، Bugهای کشف‌شده، شکاف‌های Test Case، ایده‌های Automation و یافته‌های مهم را گزارش می‌کنم.

🎤 سؤال ۱۱: Exploratory Testing در Agile چه مزیتی دارد؟

پاسخ پیشنهادی: انعطاف‌پذیری این رویکرد با تغییرات سریع و نیاز به بازخورد مداوم در Agile سازگار است و به QA کمک می‌کند ریسک‌های Featureهای جدید را سریع‌تر بررسی کند.

🎤 سؤال ۱۲: آیا QA Junior هم می‌تواند Exploratory Testing انجام دهد؟

پاسخ پیشنهادی: بله. تجربه بیشتر کیفیت تست را افزایش می‌دهد، اما Juniorها نیز می‌توانند با استفاده از Charter، Checklist، Heuristic و بازخورد QAهای باتجربه این مهارت را توسعه دهند.

❓ سوالات متداول درباره Exploratory Testing

در این بخش سوالات متداولی که در مورد موضوع تست اکتشافی پرسیده می‌شود آورده شده است.

🏁 جمع‌بندی؛ Exploratory Testing فقط تست کردن نیست

اگر تا اینجا همراه ما بوده‌اید، احتمالاً دیگر Exploratory Testing را صرفاً به‌عنوان «تست کردن بدون Test Case» نمی‌بینید.

Exploratory Testing در واقع یک رویکرد برای یادگیری، فکر کردن، طراحی تست و کشف ریسک است؛ رویکردی که به تستر اجازه می‌دهد در طول بررسی یک سیستم، بر اساس اطلاعات جدید مسیر خود را تغییر دهد.

اما مهم‌ترین نکته این مقاله شاید این باشد:

Exploratory Testing قرار نیست جای Test Case، Automation Testing یا سایر روش‌های QA را بگیرد.

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

یک تیم QA بالغ به‌جای اینکه از خود بپرسد «کدام روش بهتر است؟»، سؤال دقیق‌تری می‌پرسد:

«برای این Feature، با این سطح از ریسک و در این مرحله از پروژه، کدام ترکیب از روش‌های تست بیشترین ارزش را ایجاد می‌کند؟»

گاهی پاسخ یک Test Case ساده است.

گاهی یک Automation Test.

گاهی یک Session هدفمند Exploratory Testing.

و در بسیاری از پروژه‌های واقعی، بهترین پاسخ ترکیبی از همه این‌هاست.

🧠 نگاه یک QA حرفه‌ای

QA حرفه‌ای فقط نمی‌پرسد:

«آیا سیستم طبق چیزی که انتظار داشتیم کار می‌کند؟»

او سؤال‌های سخت‌تری می‌پرسد:

• اگر کاربر برخلاف انتظار رفتار کند چه؟
• اگر شرایط محیطی تغییر کند چه؟
• اگر دو رویداد هم‌زمان رخ دهند چه؟
• اگر یکی از فرضیات اصلی ما اشتباه باشد چه؟
• اگر مشتری فردا سناریویی را اجرا کند که امروز هیچ‌کس به آن فکر نکرده است چه؟

همین نوع سؤال‌هاست که Exploratory Testing را از یک فعالیت ساده به یک مهارت حرفه‌ای تبدیل می‌کند.

💙 هدف یک QA حرفه‌ای پیدا کردن همه Bugها نیست؛ هدف، کاهش ریسک‌های مهم قبل از رسیدن آن‌ها به دست مشتری است.

🎯 اگر فقط سه نکته از این مقاله را به خاطر بسپارید…

• ✅ Exploratory Testing تست تصادفی نیست. این رویکرد بر یادگیری، مشاهده، طراحی تست و تصمیم‌گیری آگاهانه استوار است.
• ✅ Exploratory Testing جایگزین همه روش‌های تست نیست. ارزش واقعی آن در ترکیب هوشمندانه با Test Case، Automation و سایر تکنیک‌های QA مشخص می‌شود.
• ✅ هدف اصلی QA فقط Bug Hunting نیست. هدف مهم‌تر، کشف و کاهش ریسک‌هایی است که می‌توانند به کاربر و کسب‌وکار آسیب بزنند.

🚀 قدم بعدی چیست؟

حالا که با Exploratory Testing آشنا شدید، برای درک بهتر جایگاه آن در فرآیند تست نرم‌افزار پیشنهاد می‌کنیم مطالعه را با این موضوعات ادامه دهید:

• 🔗 Test Case چیست؟ برای درک تفاوت بین تست ساختاریافته و Exploratory Testing.
• 🔗 Test Scenario چیست؟ برای یادگیری طراحی سناریوهای سطح بالا.
• 🔗 Manual Testing چیست؟ برای درک جایگاه تست دستی در چرخه QA.
• 🔗 Regression Testing چیست؟ برای مقایسه Regression ساختاریافته با Exploratory Regression.
• 🔗 Bug Report چیست؟ برای یادگیری نحوه گزارش حرفه‌ای یافته‌های تست.
• 🔗 Agile Testing چیست؟ برای درک نقش QA در تیم‌های Agile.
• 🔗 Automation Testing چیست؟ برای شناخت رابطه Automation و Exploratory Testing.

💡 پیشنهاد حرفه‌ای: یکی از بهترین راه‌های یادگیری Exploratory Testing این است که یک Feature واقعی انتخاب کنید، یک Session کوتاه طراحی کنید، Charter بنویسید، Time Box تعیین کنید و در پایان دقیقاً ثبت کنید که چه چیزهایی یاد گرفته‌اید.

💙 حرف آخر

یک نرم‌افزار ممکن است تمام Test Caseهای خود را Pass کرده باشد، Pipeline آن سبز باشد و هیچ تست خودکاری Fail نشده باشد؛ اما هنوز ناشناخته‌هایی وجود داشته باشند که هیچ‌کس آن‌ها را بررسی نکرده است.

Exploratory Testing به ما یادآوری می‌کند که کیفیت فقط اجرای فهرستی از تست‌ها نیست.

کیفیت یعنی سؤال پرسیدن، شک کردن، مشاهده کردن، یاد گرفتن و کشف کردن.

و شاید مهم‌ترین مهارتی که یک QA Engineer می‌تواند در طول مسیر حرفه‌ای خود به دست آورد، همین باشد:

توانایی دیدن چیزی که دیگران هنوز ندیده‌اند.

این دقیقاً جایی است که Exploratory Testing ارزش واقعی خود را نشان می‌دهد.