سناریو تست (Test Scenario) چیست؟ راهنمای جامع

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

اینجاست که مفهوم سناریو تست (Test Scenario) اهمیت پیدا می‌کند. سناریو تست به تستر کمک می‌کند مشخص کند چه رفتار یا شرایطی از سیستم باید مورد بررسی قرار گیرد؛ بدون اینکه در این مرحله وارد جزئیات اجرای تست، داده‌های آزمایشی و مراحل گام‌به‌گام شویم.

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

درک درست سناریو تست اهمیت زیادی دارد، زیرا این مفهوم گاهی با تست کیس، نیازمندی (Requirement)، معیار پذیرش (Acceptance Criteria) و User Story اشتباه گرفته می‌شود. هرکدام از این مفاهیم نقش متفاوتی در فرآیند توسعه و تست نرم‌افزار دارند و شناخت ارتباط آن‌ها به طراحی تست‌های کامل‌تر و منظم‌تر کمک می‌کند.

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

۲. سناریو تست (Test Scenario) چیست؟

سناریو تست (Test Scenario) یک وضعیت، رفتار، قابلیت یا شرایط مشخص از نرم‌افزار است که باید از طریق تست بررسی شود. به زبان ساده، سناریو تست به تستر کمک می‌کند مشخص کند چه چیزی باید تست شود.

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

• بررسی ورود کاربر با اطلاعات معتبر
• بررسی ورود با رمز عبور اشتباه
• بررسی ورود با ایمیل نامعتبر
• بررسی ورود بدون وارد کردن اطلاعات لازم
• بررسی رفتار سیستم پس از چند تلاش ناموفق برای ورود

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

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

برای نمونه:

سناریو تست: بررسی ورود موفق کاربر با اطلاعات معتبر

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

بنابراین می‌توان گفت:

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

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

۳. سناریو تست چه چیزی را مشخص می‌کند؟

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

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

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

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

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

• بررسی افزودن یک محصول موجود به سبد خرید
• بررسی افزودن چند محصول به سبد خرید
• بررسی افزودن محصول ناموجود به سبد خرید
• بررسی افزودن محصولی که موجودی آن به پایان رسیده است
• بررسی تغییر تعداد محصول در سبد خرید

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

سناریو تست چه چیزی را مشخص نمی‌کند؟

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

برای مثال، اگر سناریو این باشد:

بررسی ورود موفق کاربر با اطلاعات معتبر

موارد زیر معمولاً مربوط به جزئیات اجرای تست هستند:

• آدرس دقیق صفحه ورود
• ایمیل مورد استفاده
• رمز عبور مورد استفاده
• ترتیب دقیق کلیک‌ها و اقدامات
• مراحل گام‌به‌گام اجرای تست
• نتیجه مورد انتظار با جزئیات کامل

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

برای مثال:

سناریو تست:

بررسی ورود موفق کاربر با اطلاعات معتبر

تست کیس:

1. صفحه ورود را باز کنید.
2. یک ایمیل معتبر وارد کنید.
3. یک رمز عبور معتبر وارد کنید.
4. روی دکمه ورود کلیک کنید.
5. بررسی کنید که کاربر به صفحه حساب کاربری منتقل شده است.

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

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

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

۴. یک مثال ساده از سناریو تست

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

فرض کنید یکی از قابلیت‌های سیستم این است:

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

تستر برای بررسی این قابلیت می‌تواند سناریوهای مختلفی را در نظر بگیرد:

• بررسی افزودن یک محصول موجود به سبد خرید
• بررسی افزودن چند محصول مختلف به سبد خرید
• بررسی افزودن محصول ناموجود به سبد خرید
• بررسی افزودن محصولی که موجودی آن به پایان رسیده است
• بررسی تغییر تعداد محصول در سبد خرید

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

برای مثال، سناریوی زیر را در نظر بگیرید:

بررسی افزودن یک محصول موجود به سبد خرید

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

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

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

چرا چند سناریو برای یک قابلیت داریم؟

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

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

بررسی افزودن یک محصول موجود به سبد خرید

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

بنابراین هنگام طراحی سناریوهای تست باید علاوه بر مسیر اصلی و موفق سیستم (Happy Path)، شرایط جایگزین و نامعتبر را نیز در نظر گرفت.

مسیر اصلی:

افزودن محصول موجود به سبد خرید

شرایط جایگزین یا منفی:

• افزودن محصول ناموجود به سبد خرید
• افزودن محصول با موجودی صفر
• افزودن تعداد بیشتر از موجودی محصول

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

۵. سناریو تست چگونه از نیازمندی استخراج می‌شود؟

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

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

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

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

تستر می‌تواند با توجه به این نیازمندی و سایر اطلاعات موجود، سناریوهای زیر را در نظر بگیرد:

• بررسی افزودن یک محصول موجود به سبد خرید
• بررسی افزودن چند محصول به سبد خرید
• بررسی افزودن محصول ناموجود به سبد خرید
• بررسی افزودن محصولی با موجودی صفر
• بررسی افزودن تعداد بیشتر از موجودی محصول

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

از یک Requirement چگونه سناریوهای مختلف استخراج می‌کنیم؟

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

۱. مسیر اصلی سیستم چیست؟

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

مثلاً:

افزودن یک محصول موجود به سبد خرید

۲. چه شرایط جایگزینی ممکن است وجود داشته باشد؟

آیا وضعیت دیگری وجود دارد که کاربر یا سیستم ممکن است با آن مواجه شود؟

مثلاً:

محصول انتخاب‌شده موجود نیست.

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

مثلاً:

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

۴. چه مرزها یا شرایط خاصی باید بررسی شوند؟

مثلاً محصول دقیقاً یک واحد موجودی دارد و کاربر می‌خواهد یک واحد یا دو واحد از آن را به سبد خرید اضافه کند.

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

یک Requirement می‌تواند چند سناریو تست داشته باشد

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

برای مثال:

سناریو تست	وضعیت مورد بررسی
افزودن محصول موجود	مسیر اصلی
افزودن چند محصول	شرایط معمول دیگر
افزودن محصول ناموجود	شرایط منفی
افزودن تعداد بیشتر از موجودی	شرایط مرزی یا منفی
افزودن محصول با موجودی صفر	شرایط منفی

بنابراین می‌توان ارتباط ساده زیر را در نظر گرفت:

Requirement → شناسایی رفتارها و شرایط قابل تست → سناریوهای تست

در ادامه، هر سناریوی مناسب می‌تواند مبنایی برای طراحی تست کیس قرار گیرد.

نکته مهم این است که Requirement تنها منبع طراحی سناریو نیست. بسته به نوع پروژه و فرآیند تیم، مواردی مانند User Story، معیارهای پذیرش، Use Case، مستندات محصول و ریسک‌های شناسایی‌شده نیز می‌توانند در طراحی سناریو تست مورد استفاده قرار گیرند.

۶. مراحل طراحی و نوشتن سناریو تست

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

برای طراحی سناریوهای مناسب می‌توان مراحل زیر را دنبال کرد.

مرحله ۱: نیازمندی یا مبنای تست را بررسی کنید

ابتدا باید مشخص شود دقیقاً چه قابلیت، رفتار یا بخشی از سیستم قرار است بررسی شود.

این اطلاعات می‌تواند از منابع مختلفی مانند Requirement، User Story، معیارهای پذیرش، Use Case یا مستندات محصول به دست آید.

برای مثال:

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

در این مرحله هنوز سناریو نمی‌نویسیم؛ ابتدا باید رفتار مورد انتظار سیستم را به‌درستی درک کنیم.

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

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

برای مثال:

بررسی افزودن محصول موجود به سبد خرید

این سناریو مسیر اصلی و مورد انتظار سیستم را پوشش می‌دهد.

مرحله ۳: شرایط جایگزین را بررسی کنید

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

• کاربر چند محصول مختلف را به سبد اضافه کند.
• کاربر تعداد محصول را افزایش دهد.
• کاربر محصولی را انتخاب کند که موجودی آن تغییر کرده است.

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

مرحله ۴: شرایط منفی و خطاها را شناسایی کنید

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

• بررسی افزودن محصول ناموجود به سبد خرید
• بررسی افزودن تعداد بیشتر از موجودی
• بررسی رفتار سیستم هنگام از دست رفتن ارتباط با سرور

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

مرحله ۵: شرایط مرزی و خاص را در نظر بگیرید

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

برای مثال، اگر موجودی یک محصول ۱۰ عدد باشد، می‌توان موارد زیر را بررسی کرد:

• افزودن دقیقاً ۱۰ عدد
• تلاش برای افزودن ۱۱ عدد
• افزودن تعداد صفر
• تلاش برای وارد کردن تعداد منفی

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

مرحله ۶: سناریوها را واضح و مستقل بنویسید

هر سناریو باید موضوع مشخصی برای بررسی داشته باشد و خواننده بتواند بدون نیاز به توضیحات اضافی متوجه شود چه چیزی قرار است تست شود.

نامناسب:

بررسی سبد خرید

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

مناسب‌تر:

بررسی افزودن محصول موجود به سبد خرید

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

مرحله ۷: سناریوهای تکراری را حذف کنید

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

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

مرحله ۸: پوشش سناریوها را بررسی کنید

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

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

بررسی افزودن محصول موجود به سبد خرید

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

بنابراین باید بررسی کنیم که علاوه بر Happy Path، شرایط جایگزین، منفی و در صورت نیاز مرزی نیز در سناریوها پوشش داده شده باشند.

خلاصه مراحل:

بررسی مبنای تست → شناسایی رفتار اصلی → شناسایی شرایط جایگزین → بررسی شرایط منفی و خطا → بررسی شرایط خاص و مرزی → نوشتن سناریوهای واضح → حذف موارد تکراری → بررسی پوشش تست

۷. سناریو تست مثبت و منفی

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

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

سناریو تست مثبت چیست؟

سناریو تست مثبت (Positive Test Scenario) سناریویی است که رفتار سیستم را در شرایط معتبر و مورد انتظار بررسی می‌کند.

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

بررسی افزودن یک محصول موجود به سبد خرید

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

چند مثال دیگر:

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

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

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

سناریو تست منفی (Negative Test Scenario) شرایطی را بررسی می‌کند که ورودی، وضعیت یا نحوه استفاده از سیستم معتبر یا مورد انتظار نیست.

برای مثال، در قابلیت افزودن محصول به سبد خرید:

بررسی افزودن محصولی که موجود نیست به سبد خرید

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

نمونه‌های دیگر:

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

هدف تست منفی این نیست که سیستم حتماً «موفق» شود؛ بلکه باید مشخص شود سیستم در شرایط نامعتبر، رفتار کنترل‌شده و مورد انتظار دارد.

یک مثال ساده از هر دو نوع سناریو

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

سناریو تست مثبت:

بررسی ورود کاربر با ایمیل و رمز عبور معتبر

سناریوهای تست منفی:

• بررسی ورود با رمز عبور اشتباه
• بررسی ورود با ایمیل نامعتبر
• بررسی ورود بدون وارد کردن رمز عبور
• بررسی ورود بدون تکمیل ایمیل و رمز عبور

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

چرا سناریوهای منفی اهمیت دارند؟

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

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

بنابراین هنگام طراحی سناریو تست بهتر است این سؤال را فقط نپرسیم:

«اگر همه چیز درست پیش برود، سیستم چگونه کار می‌کند؟»

بلکه سؤال دیگری نیز مطرح کنیم:

«اگر شرایط معتبر نباشد یا مشکلی در فرآیند رخ دهد، سیستم چگونه باید رفتار کند؟»

۸. سناریوی Happy Path و مسیرهای جایگزین

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

Happy Path مسیری است که در آن کاربر و سیستم شرایط مورد انتظار را دارند و فرآیند بدون خطا یا استثنای خاصی پیش می‌رود.

برای مثال، در یک فروشگاه اینترنتی، فرآیند خرید می‌تواند به این شکل باشد:

انتخاب محصول → افزودن به سبد خرید → ثبت سفارش → پرداخت موفق → ثبت نهایی سفارش

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

بررسی ثبت موفق سفارش با محصول موجود و پرداخت موفق

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

آیا Happy Path همان سناریو تست مثبت است؟

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

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

برای مثال در فرآیند خرید:

Happy Path: خرید یک محصول موجود با پرداخت موفق

اما این مورد نیز می‌تواند یک سناریوی مثبت باشد:

خرید چند محصول موجود با استفاده از روش پرداخت معتبر

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

مسیرهای جایگزین چیستند؟

در یک فرآیند نرم‌افزاری، ممکن است کاربر از مسیر اصلی فاصله بگیرد، اما همچنان یک رفتار معتبر یا قابل پیش‌بینی داشته باشد. این وضعیت‌ها را می‌توان به عنوان Alternative Path در نظر گرفت.

برای مثال، در فرآیند خرید:

Happy Path:

انتخاب محصول → سبد خرید → پرداخت → ثبت سفارش

Alternative Path:

انتخاب چند محصول → سبد خرید → حذف یکی از محصولات → پرداخت → ثبت سفارش

در این حالت فرآیند خرید همچنان معتبر است، اما مسیر آن با مسیر اصلی متفاوت شده است.

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

مسیرهای استثنایی و خطا

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

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

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

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

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

بنابراین هنگام طراحی سناریو تست بهتر است فرآیند را از چند زاویه بررسی کنیم:

Happy Path → مسیرهای جایگزین → شرایط استثنایی و خطا

۹. ارتباط سناریو تست با تست کیس

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

به زبان ساده:

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

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

سناریو تست:

بررسی افزودن یک محصول موجود به سبد خرید

این سناریو فقط موضوعی را که باید تست شود مشخص می‌کند.

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

در این مرحله می‌توان سناریو را به یک تست کیس تبدیل کرد:

پیش‌شرط: کاربر وارد حساب کاربری شده و محصول موردنظر موجود است.

1. صفحه محصول را باز کنید.
2. روی گزینه «افزودن به سبد خرید» کلیک کنید.
3. سبد خرید را باز کنید.

نتیجه مورد انتظار: محصول انتخاب‌شده باید با تعداد صحیح در سبد خرید نمایش داده شود.

یک سناریو می‌تواند به چند تست کیس منجر شود

یکی از نکات مهم این است که رابطه بین سناریو تست و تست کیس الزاماً یک‌به‌یک نیست.

برای مثال، سناریوی زیر را در نظر بگیرید:

بررسی ورود موفق کاربر

برای بررسی این سناریو ممکن است تست کیس‌های مختلفی طراحی شوند؛ برای مثال:

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

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

تفاوت سناریو تست و تست کیس در یک نگاه

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

در نتیجه، اگر بخواهیم رابطه این دو مفهوم را در یک جمله خلاصه کنیم:

سناریو تست مشخص می‌کند «چه چیزی را تست کنیم؟» و تست کیس مشخص می‌کند «چگونه آن را تست کنیم؟»

۱۰. تفاوت سناریو تست و نیازمندی

نیازمندی (Requirement) و سناریو تست ارتباط نزدیکی با یکدیگر دارند، اما هدف متفاوتی دارند.

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

به بیان ساده:

نیازمندی می‌گوید سیستم چه چیزی باید ارائه دهد؛ سناریو تست مشخص می‌کند چه چیزی از آن را باید تست کنیم.

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

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

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

• بررسی افزودن یک محصول موجود به سبد خرید
• بررسی افزودن چند محصول به سبد خرید
• بررسی افزودن محصول ناموجود به سبد خرید
• بررسی افزودن تعداد بیشتر از موجودی محصول
• بررسی رفتار سیستم هنگام تغییر موجودی محصول

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

تفاوت نیازمندی و سناریو تست در یک مثال

فرض کنید نیازمندی سیستم این باشد:

کاربر باید بتواند با وارد کردن اطلاعات معتبر وارد حساب کاربری خود شود.

از این نیازمندی می‌توان سناریوهای مختلفی استخراج کرد:

نیازمندی: امکان ورود کاربر با اطلاعات معتبر

سناریوهای تست:

• بررسی ورود موفق با اطلاعات معتبر
• بررسی ورود با رمز عبور اشتباه
• بررسی ورود با ایمیل نامعتبر
• بررسی ورود بدون تکمیل اطلاعات لازم

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

آیا هر نیازمندی فقط یک سناریو تست دارد؟

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

برای مثال:

نیازمندی: کاربر باید بتواند رمز عبور خود را بازیابی کند.

این نیازمندی می‌تواند سناریوهای مختلفی ایجاد کند:

• بررسی بازیابی رمز عبور با ایمیل معتبر
• بررسی بازیابی رمز عبور با ایمیل ثبت‌نشده
• بررسی ارسال مجدد لینک بازیابی
• بررسی استفاده از لینک بازیابی منقضی‌شده
• بررسی استفاده مجدد از لینک بازیابی پس از تغییر رمز عبور

بنابراین رابطه این دو مفهوم را می‌توان به شکل زیر خلاصه کرد:

نیازمندی → شناسایی رفتارها و شرایط قابل تست → سناریوهای تست

سپس در مرحله بعد، سناریوهای تست می‌توانند مبنایی برای طراحی تست کیس‌ها قرار بگیرند.

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

۱۱. تفاوت سناریو تست و معیار پذیرش

معیار پذیرش (Acceptance Criteria) و سناریو تست هر دو می‌توانند در شناسایی موارد قابل تست به تستر کمک کنند، اما هدف و جایگاه آن‌ها متفاوت است.

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

به زبان ساده:

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

یک مثال ساده

فرض کنید در یک فروشگاه اینترنتی، User Story این باشد:

به عنوان یک کاربر، می‌خواهم محصول موردنظر خود را به سبد خرید اضافه کنم تا بتوانم سفارش خود را ثبت کنم.

معیارهای پذیرش می‌توانند شامل موارد زیر باشند:

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

تستر می‌تواند با بررسی این معیارها، سناریوهای تست مختلفی را شناسایی کند:

• بررسی افزودن محصول موجود به سبد خرید
• بررسی نمایش تعداد صحیح محصول در سبد خرید
• بررسی افزودن تعداد بیشتر از موجودی
• بررسی افزودن محصول ناموجود

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

آیا معیار پذیرش و سناریو تست می‌توانند شبیه هم باشند؟

بله. گاهی یک معیار پذیرش آن‌قدر مشخص و قابل تست نوشته شده است که می‌تواند تقریباً مستقیماً به یک سناریو تست تبدیل شود.

معیار پذیرش:

کاربر باید بتواند با وارد کردن اطلاعات معتبر وارد حساب کاربری شود.

سناریو تست:

بررسی ورود موفق کاربر با اطلاعات معتبر

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

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

تفاوت در یک جدول

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

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

بنابراین:

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

۱۲. تفاوت سناریو تست و User Story

User Story و سناریو تست هر دو با رفتار مورد انتظار نرم‌افزار ارتباط دارند، اما هدف متفاوتی دارند.

User Story نیاز یک کاربر یا ذی‌نفع را از دید کاربر بیان می‌کند؛ در حالی که سناریو تست مشخص می‌کند کدام رفتار یا شرایط سیستم باید بررسی شود.

به زبان ساده:

User Story می‌گوید کاربر چه چیزی می‌خواهد و چرا؛ سناریو تست مشخص می‌کند چه چیزی از سیستم باید تست شود.

یک مثال ساده

فرض کنید در یک فروشگاه اینترنتی، User Story به شکل زیر نوشته شده باشد:

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

این User Story نیاز کاربر و هدف او را بیان می‌کند.

تستر با بررسی این User Story و معیارهای پذیرش آن می‌تواند سناریوهای تست مختلفی را شناسایی کند:

• بررسی افزودن یک محصول موجود به سبد خرید
• بررسی افزودن چند محصول به سبد خرید
• بررسی افزودن محصول ناموجود
• بررسی افزودن تعداد بیشتر از موجودی
• بررسی تغییر تعداد محصول در سبد خرید
• بررسی حذف محصول از سبد خرید

در اینجا User Story مشخص می‌کند کاربر چه نیازی دارد، اما سناریوهای تست مشخص می‌کنند چه شرایط و رفتارهایی از سیستم باید بررسی شوند.

آیا User Story خودش یک سناریو تست است؟

خیر.

برای مثال:

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

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

تستر می‌تواند بر اساس آن سناریوهایی مانند موارد زیر طراحی کند:

• بررسی ورود با ایمیل و رمز عبور معتبر
• بررسی ورود با رمز عبور اشتباه
• بررسی ورود با ایمیل نامعتبر
• بررسی ورود با اطلاعات ناقص
• بررسی رفتار سیستم پس از چند تلاش ناموفق

بنابراین یک User Story می‌تواند به چند سناریو تست منجر شود.

تفاوت User Story و سناریو تست در یک نگاه

User Story	سناریو تست
نیاز کاربر را بیان می‌کند.	رفتار یا شرایط قابل تست را مشخص می‌کند.
معمولاً از دید کاربر نوشته می‌شود.	معمولاً از دید تست و بررسی سیستم نوشته می‌شود.
توضیح می‌دهد کاربر چه می‌خواهد و چرا.	مشخص می‌کند چه چیزی باید بررسی شود.
می‌تواند شامل معیارهای پذیرش باشد.	می‌تواند مبنای طراحی تست کیس باشد.
یکی از منابع طراحی سناریوهای تست است.	یکی از خروجی‌های فرآیند تحلیل و طراحی تست است.

رابطه User Story، معیار پذیرش و سناریو تست

در پروژه‌های Agile معمولاً این مفاهیم در کنار یکدیگر قرار می‌گیرند.

User Story:

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

معیارهای پذیرش:

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

سناریوهای تست:

• بررسی ورود موفق با اطلاعات معتبر
• بررسی ورود با رمز عبور اشتباه
• بررسی ورود بدون تکمیل اطلاعات لازم

در نهایت برای هر سناریو می‌توان یک یا چند تست کیس طراحی کرد.

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

User Story → معیارهای پذیرش → سناریوهای تست → تست کیس‌ها

البته این رابطه همیشه یک مسیر ثابت و اجباری نیست. تستر می‌تواند از منابع دیگری مانند Requirement، مستندات محصول، Use Case و ریسک‌های سیستم نیز برای شناسایی سناریوهای تست استفاده کند.

در نتیجه، User Story معمولاً درباره نیاز و هدف کاربر صحبت می‌کند، در حالی که سناریو تست درباره شرایط و رفتارهایی که باید بررسی شوند صحبت می‌کند.

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

User Story نقطه شروع مناسبی برای درک نیاز کاربر است؛ سناریو تست نتیجه تحلیل آن نیاز از دید تست است.

۱۳. تفاوت سناریو تست، تست کیس، نیازمندی، معیار پذیرش و User Story در یک مثال

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

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

۱. نیازمندی (Requirement)

ابتدا نیازمندی سیستم را در نظر می‌گیریم:

سیستم باید به کاربر اجازه دهد محصولات موجود را به سبد خرید اضافه کند.

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

۲. User Story

همین نیاز می‌تواند در قالب یک User Story نیز بیان شود:

به عنوان یک کاربر، می‌خواهم بتوانم محصول موردنظر خود را به سبد خرید اضافه کنم تا بتوانم آن را خریداری کنم.

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

۳. معیارهای پذیرش

برای مشخص کردن شرایط پذیرش این قابلیت، می‌توان معیارهای زیر را در نظر گرفت:

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

معیارهای پذیرش مشخص می‌کنند این قابلیت برای پذیرفته شدن چه شرایطی باید داشته باشد.

۴. سناریوهای تست

حالا تستر با بررسی نیازمندی، User Story، معیارهای پذیرش و سایر اطلاعات موجود، مواردی را که باید بررسی شوند شناسایی می‌کند:

• بررسی افزودن یک محصول موجود به سبد خرید
• بررسی افزودن چند محصول به سبد خرید
• بررسی افزودن تعداد بیشتر از موجودی
• بررسی افزودن محصول ناموجود
• بررسی نمایش تعداد صحیح محصول در سبد خرید
• بررسی تغییر تعداد محصول در سبد خرید
• بررسی حذف محصول از سبد خرید

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

۵. تست کیس

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

برای مثال، برای سناریوی زیر:

بررسی افزودن یک محصول موجود به سبد خرید

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

پیش‌شرط:
کاربر وارد حساب کاربری شده و محصول موردنظر موجود است.

مراحل:

1. صفحه محصول را باز کنید.
2. روی گزینه «افزودن به سبد خرید» کلیک کنید.
3. سبد خرید را باز کنید.

نتیجه مورد انتظار:
محصول باید با تعداد صحیح در سبد خرید نمایش داده شود.

در اینجا برخلاف سناریو تست، جزئیات اجرای تست مشخص شده است.

همه مفاهیم در یک نگاه

مفهوم	سؤال اصلی	مثال
Requirement	سیستم چه چیزی باید ارائه دهد؟	سیستم باید امکان افزودن محصول موجود به سبد خرید را فراهم کند.
User Story	کاربر چه می‌خواهد و چرا؟	کاربر می‌خواهد محصول را به سبد خرید اضافه کند تا بتواند آن را خریداری کند.
معیار پذیرش	قابلیت برای پذیرفته شدن چه شرایطی باید داشته باشد؟	محصول موجود باید به سبد اضافه شود و محصول ناموجود قابل افزودن نباشد.
سناریو تست	چه چیزی را باید بررسی کنیم؟	بررسی افزودن محصول موجود به سبد خرید
تست کیس	این مورد را دقیقاً چگونه تست کنیم؟	ورود به صفحه محصول → افزودن به سبد → بررسی سبد

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

Requirement / User Story
↓
معیارهای پذیرش و سایر اطلاعات مرتبط
↓
سناریوهای تست
↓
تست کیس‌ها

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

نکته کلیدی

مهم‌ترین تفاوت این مفاهیم در هدف و سطح جزئیات آن‌هاست.

Requirement نیاز یا قابلیت موردنیاز سیستم را بیان می‌کند.
User Story همان نیاز را از دید کاربر و با تمرکز بر هدف او بیان می‌کند.
معیار پذیرش شرایطی را مشخص می‌کند که قابلیت باید برای پذیرفته شدن برآورده کند.
سناریو تست رفتارها و شرایطی را که باید بررسی شوند مشخص می‌کند.
تست کیس نحوه اجرای یک بررسی مشخص و نتیجه مورد انتظار آن را با جزئیات بیشتری تعریف می‌کند.

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

۱۴. چند مثال واقعی از سناریو تست

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

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

مثال اول: ورود به حساب کاربری

فرض کنید یک نرم‌افزار امکان ورود کاربران با ایمیل و رمز عبور را فراهم می‌کند.

• بررسی ورود با ایمیل و رمز عبور معتبر
• بررسی ورود با رمز عبور اشتباه
• بررسی ورود با ایمیل ثبت‌نشده
• بررسی ورود با فرمت نامعتبر ایمیل
• بررسی ورود بدون وارد کردن ایمیل
• بررسی ورود بدون وارد کردن رمز عبور
• بررسی ورود بدون تکمیل اطلاعات
• بررسی رفتار سیستم پس از چند تلاش ناموفق

در این مثال، فقط بررسی ورود موفق کافی نیست؛ زیرا سیستم باید در شرایط نامعتبر و غیرعادی نیز رفتار قابل قبولی داشته باشد.

مثال دوم: ثبت‌نام کاربر

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

• بررسی ثبت‌نام با اطلاعات معتبر
• بررسی ثبت‌نام با ایمیل تکراری
• بررسی ثبت‌نام با ایمیل نامعتبر
• بررسی ثبت‌نام بدون تکمیل فیلدهای الزامی
• بررسی ثبت‌نام با رمز عبور نامعتبر
• بررسی تطابق رمز عبور و تکرار رمز عبور
• بررسی رفتار سیستم در برابر داده‌های ورودی بسیار طولانی
• بررسی ارسال موفق کد یا لینک تأیید حساب

مثال سوم: جستجوی محصول

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

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

مثال چهارم: سبد خرید

برای قابلیت سبد خرید می‌توان سناریوهای زیر را در نظر گرفت:

• بررسی افزودن یک محصول موجود به سبد خرید
• بررسی افزودن چند محصول مختلف
• بررسی افزایش تعداد یک محصول
• بررسی کاهش تعداد یک محصول
• بررسی حذف محصول از سبد خرید
• بررسی افزودن محصول ناموجود
• بررسی افزودن تعداد بیشتر از موجودی
• بررسی محاسبه صحیح مبلغ سبد خرید
• بررسی حفظ اطلاعات سبد خرید پس از ورود یا خروج کاربر

مثال پنجم: پرداخت

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

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

مثال ششم: بازیابی رمز عبور

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

مثال هفتم: API

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

فرض کنید API مربوط به دریافت اطلاعات یک محصول باشد.

• بررسی دریافت اطلاعات محصول با شناسه معتبر
• بررسی درخواست با شناسه نامعتبر
• بررسی درخواست بدون ارسال شناسه
• بررسی رفتار API در برابر شناسه محصولی که وجود ندارد
• بررسی پاسخ API در شرایط خطای سرور
• بررسی کنترل دسترسی برای کاربر غیرمجاز

در اینجا نیز سناریو مشخص می‌کند چه رفتار یا شرایطی باید بررسی شود و جزئیات درخواست، داده‌های ورودی، Headerها، پاسخ مورد انتظار و سایر موارد می‌توانند در تست کیس یا مستندات مربوط به تست API ثبت شوند.

نکته مهم در نوشتن مثال‌ها

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

برای طراحی سناریوهای مناسب بهتر است حداقل این موارد را در نظر بگیریم:

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

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

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

۱۵. اشتباهات رایج در نوشتن سناریو تست

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

در ادامه، مهم‌ترین اشتباهات رایج را بررسی می‌کنیم.

۱. نوشتن سناریو به شکل تست کیس

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

برای مثال، این مورد بیش از حد جزئی است:

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

این متن بیشتر شبیه یک تست کیس است.

در سطح سناریو بهتر است بنویسیم:

بررسی ورود موفق کاربر با اطلاعات معتبر

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

۲. نوشتن سناریوهای بیش از حد کلی

سناریو نباید آن‌قدر کلی باشد که مشخص نباشد دقیقاً چه چیزی باید بررسی شود.

برای مثال:

تست سیستم

یا:

تست ورود

این عبارات اطلاعات کافی درباره موضوع بررسی ارائه نمی‌کنند.

بهتر است سناریو تا حدی مشخص باشد که رفتار یا شرایط موردنظر را بتوان از آن تشخیص داد:

• بررسی ورود کاربر با رمز عبور اشتباه
• بررسی جلوگیری از ورود کاربر با اطلاعات نامعتبر

هدف این نیست که سناریو را به یک تست کیس تبدیل کنیم؛ بلکه باید موضوع تست را به اندازه کافی روشن بیان کنیم.

۳. تمرکز فقط روی مسیر موفق

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

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

بررسی ورود موفق با اطلاعات معتبر

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

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

مسیر موفق (Happy Path) مهم است، اما به‌تنهایی پوشش مناسبی ایجاد نمی‌کند.

۴. نادیده گرفتن شرایط مرزی

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

برای مثال، اگر تعداد قابل سفارش یک محصول حداکثر ۱۰ عدد باشد، فقط بررسی عدد ۵ کافی نیست.

• بررسی سفارش دقیقاً ۱۰ عدد
• بررسی سفارش ۱۱ عدد
• بررسی سفارش تعداد صفر
• بررسی ورود تعداد منفی

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

۵. تکراری نوشتن سناریوها

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

• بررسی ورود با رمز اشتباه
• بررسی عدم ورود با رمز اشتباه
• بررسی جلوگیری از ورود با رمز عبور نادرست

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

سناریوها باید تا حد امکان واضح، مستقل و غیرتکراری باشند.

۶. نوشتن سناریو بدون توجه به نیازمندی و سایر منابع

سناریو نباید صرفاً بر اساس حدس تستر نوشته شود.

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

• Requirement
• User Story
• معیارهای پذیرش
• Use Case
• مستندات محصول
• قوانین کسب‌وکار
• ریسک‌های سیستم

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

۷. نادیده گرفتن شرایط خطا

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

برای مثال، در یک فرآیند پرداخت، علاوه بر اطلاعات نامعتبر، ممکن است این شرایط نیز مهم باشند:

• قطع ارتباط با درگاه
• خطای سرویس پرداخت
• Timeout
• بازگشت کاربر از درگاه بدون تکمیل پرداخت
• ارسال مجدد درخواست پرداخت

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

۸. تبدیل هر جزئیات کوچک به یک سناریوی مستقل

اشتباه دیگر، ایجاد تعداد بسیار زیادی سناریو برای جزئیاتی است که بهتر است در سطح تست کیس بررسی شوند.

برای مثال، اگر سناریو این باشد:

بررسی ورود موفق کاربر

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

• بررسی باز شدن صفحه ورود
• بررسی کلیک روی فیلد ایمیل
• بررسی وارد کردن ایمیل
• بررسی کلیک روی فیلد رمز عبور
• بررسی وارد کردن رمز عبور
• بررسی کلیک روی دکمه ورود

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

سناریو باید در سطح مناسبی از دانه‌بندی (Granularity) نوشته شود؛ نه آن‌قدر کلی که کاربرد خود را از دست بدهد و نه آن‌قدر جزئی که به فهرستی از مراحل تست تبدیل شود.

۹. تصور اینکه تعداد بیشتر سناریو همیشه بهتر است

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

ممکن است ۱۰۰ سناریوی تکراری و کم‌ارزش، پوشش واقعی کمتری نسبت به ۳۰ سناریوی خوب و هدفمند ایجاد کنند.

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

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

جمع‌بندی اشتباهات رایج

مهم‌ترین اشتباهات را می‌توان این‌گونه خلاصه کرد:

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

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

۱۶. چگونه مطمئن شویم سناریوهای تست پوشش مناسبی دارند؟

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

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

برای این کار می‌توان چند سؤال ساده اما مهم را مطرح کرد.

۱. آیا همه نیازمندی‌های مهم پوشش داده شده‌اند؟

ابتدا باید بررسی کنیم که برای هر Requirement مهم، حداقل سناریوهای مرتبط وجود داشته باشند.

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

• ثبت‌نام
• ورود
• بازیابی رمز عبور
• جستجو
• افزودن محصول به سبد خرید
• پرداخت

نباید فقط برای ورود و ثبت‌نام سناریو طراحی شود و قابلیت پرداخت بدون سناریوی تست باقی بماند.

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

Requirement → Test Scenarios

این ارتباط کمک می‌کند نیازمندی‌هایی که هیچ سناریوی مرتبطی ندارند شناسایی شوند.

۲. آیا مسیر اصلی پوشش داده شده است؟

برای هر قابلیت مهم، ابتدا باید مسیر موفق (Happy Path) یا مسیر اصلی آن را در نظر بگیریم.

برای مثال در فرآیند خرید:

انتخاب محصول → افزودن به سبد → ثبت سفارش → پرداخت → تکمیل سفارش

حداقل باید سناریویی برای بررسی اجرای موفق این فرآیند وجود داشته باشد.

اما بررسی مسیر اصلی به‌تنهایی کافی نیست.

۳. آیا شرایط منفی و نامعتبر بررسی شده‌اند؟

برای هر قابلیت مهم باید بررسی کنیم که اگر کاربر یا سیستم در شرایط غیرعادی قرار گرفت، چه اتفاقی می‌افتد.

برای مثال در ورود:

• رمز عبور اشتباه
• ایمیل نامعتبر
• اطلاعات ناقص
• حساب کاربری غیرفعال
• تلاش‌های ناموفق متوالی

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

۴. آیا مسیرهای جایگزین بررسی شده‌اند؟

ممکن است یک فرآیند بیش از یک مسیر معتبر داشته باشد.

برای مثال، در فرآیند خرید ممکن است کاربر:

• محصول را مستقیماً به سبد اضافه کند.
• ابتدا جزئیات محصول را مشاهده کند و سپس آن را اضافه کند.
• تعداد محصول را قبل از پرداخت تغییر دهد.
• یکی از محصولات سبد را حذف کند.

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

۵. آیا شرایط مرزی و خاص در نظر گرفته شده‌اند؟

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

اگر یک فیلد مثلاً حداکثر ۵۰ کاراکتر را قبول می‌کند، باید شرایط نزدیک به مرز نیز مورد توجه قرار گیرد:

• مقدار کمتر از حد مجاز
• مقدار دقیقاً برابر با حد مجاز
• مقدار بیشتر از حد مجاز
• مقدار خالی، در صورت امکان

همچنین شرایط خاص دیگری مانند منقضی شدن نشست کاربر، قطع ارتباط شبکه یا Timeout نیز ممکن است برای یک قابلیت اهمیت داشته باشند.

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

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

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

بنابراین در طراحی سناریوها باید ریسک‌های مهم را نیز در نظر گرفت.

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

به بیان ساده:

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

۷. آیا سناریوهای تکراری حذف شده‌اند؟

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

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

این کار باعث می‌شود مجموعه سناریوها:

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

یک روش ساده برای بررسی پوشش

می‌توان یک جدول ساده برای ارتباط نیازمندی‌ها و سناریوهای تست ایجاد کرد:

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

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

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

یک نکته مهم درباره پوشش

پوشش مناسب به معنی تست کردن همه حالت‌های ممکن نیست.

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

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

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

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

۱۷. آیا همیشه باید سناریو تست بنویسیم؟

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

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

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

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

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

• ثبت‌نام و ورود
• مدیریت کاربران
• جستجو
• سبد خرید
• سفارش
• پرداخت
• گزارش‌گیری

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

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

در پروژه‌های کوچک چطور؟

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

برای مثال، تستر ممکن است Requirement یا User Story را بررسی کند و مستقیماً تست کیس‌های موردنیاز را طراحی و اجرا کند.

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

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

در Agile آیا سناریو تست حذف می‌شود؟

خیر.

در تیم‌های Agile معمولاً سرعت و همکاری اهمیت زیادی دارد و ممکن است همه جزئیات تست به شکل اسناد رسمی و جداگانه ثبت نشوند.

با این حال، تستر همچنان باید هنگام تحلیل یک User Story به این موضوع فکر کند که:

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

حتی اگر این موارد در یک فایل با عنوان Test Scenario ثبت نشوند، فرآیند فکری پشت طراحی سناریو همچنان وجود دارد.

آیا می‌توان مستقیماً از Requirement به تست کیس رسید؟

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

برای مثال:

Requirement:
کاربر باید بتواند با اطلاعات معتبر وارد حساب کاربری شود.

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

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

بنابراین سناریو تست را نباید یک مرحله کاملاً اجباری و یکسان برای همه تیم‌ها در نظر گرفت.

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

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

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

یک نکته مهم

نباید هدف از سناریو تست را صرفاً تولید یک سند دیگر بدانیم.

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

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

در نتیجه:

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

۱۸. Checklist طراحی سناریو تست

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

بررسی منبع و محدوده

• آیا Requirement، User Story یا سایر منابع مرتبط بررسی شده‌اند؟
• آیا قابلیت یا رفتار اصلی سیستم به‌درستی شناسایی شده است؟
• آیا محدوده تست مشخص است؟
• آیا نیازمندی‌های مهم بدون سناریو باقی نمانده‌اند؟

بررسی انواع شرایط

• آیا مسیر موفق (Happy Path) یا مسیر اصلی پوشش داده شده است؟
• آیا مسیرهای جایگزین بررسی شده‌اند؟
• آیا شرایط منفی و ورودی‌های نامعتبر در نظر گرفته شده‌اند؟
• آیا شرایط خطا و استثنا بررسی شده‌اند؟
• آیا شرایط مرزی و مقادیر حداقل و حداکثر در نظر گرفته شده‌اند؟
• آیا شرایط خاصی که احتمال وقوع یا اهمیت زیادی دارند بررسی شده‌اند؟

بررسی کیفیت سناریوها

• آیا هر سناریو موضوع مشخص و قابل درکی دارد؟
• آیا سناریو بیش از حد کلی نیست؟
• آیا سناریو بیش از حد جزئی و شبیه تست کیس نشده است؟
• آیا سناریوهای تکراری حذف شده‌اند؟
• آیا هر سناریو ارزش تستی مشخصی دارد؟
• آیا سناریوها در سطح مناسبی از جزئیات نوشته شده‌اند؟

بررسی پوشش و ریسک

• آیا قابلیت‌های مهم و پرریسک پوشش داده شده‌اند؟
• آیا سناریوها فقط روی مسیرهای موفق تمرکز نکرده‌اند؟
• آیا رفتار سیستم در شرایط واقعی استفاده نیز در نظر گرفته شده است؟
• آیا تعداد سناریوها متناسب با اهمیت و پیچیدگی قابلیت است؟
• آیا سناریوی مهمی وجود دارد که فقط به دلیل نبودن آن در Requirement یا معیار پذیرش نادیده گرفته شده باشد؟

بررسی ارتباط با تست کیس

• آیا هر سناریو می‌تواند مبنای طراحی یک یا چند تست کیس قرار گیرد؟
• آیا جزئیات اجرای تست به اشتباه وارد سناریو نشده است؟
• آیا مشخص است برای کدام سناریوها نیاز به چند تست کیس وجود دارد؟

Checklist نهایی

اگر بخواهیم این بررسی را در چند سؤال کوتاه خلاصه کنیم، قبل از نهایی کردن سناریوهای تست از خودمان بپرسیم:

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

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

۱۹. جمع‌بندی

سناریو تست (Test Scenario) یکی از مفاهیم مهم در تحلیل و طراحی تست نرم‌افزار است که به تستر کمک می‌کند قبل از ورود به جزئیات اجرای تست، مشخص کند چه رفتارها، قابلیت‌ها و شرایطی از سیستم باید بررسی شوند.

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

سناریوهای تست می‌توانند از منابع مختلفی مانند Requirement، User Story، معیارهای پذیرش، Use Case، مستندات محصول و ریسک‌های سیستم شناسایی شوند. همچنین تستر نباید فقط به مسیر اصلی و شرایط موفق توجه کند؛ بلکه شرایط منفی، مسیرهای جایگزین، شرایط مرزی و خطاهای مهم نیز باید در نظر گرفته شوند.

در طول مقاله دیدیم که:

• Requirement مشخص می‌کند سیستم چه نیاز یا قابلیتی باید داشته باشد.
• User Story نیاز کاربر و هدف او را بیان می‌کند.
• معیار پذیرش مشخص می‌کند یک قابلیت برای پذیرفته شدن چه شرایطی باید داشته باشد.
• سناریو تست مشخص می‌کند چه رفتار یا شرایطی باید بررسی شود.
• تست کیس نحوه اجرای یک بررسی مشخص را با جزئیات بیشتری تعریف می‌کند.

بنابراین می‌توان رابطه این مفاهیم را به‌صورت ساده این‌گونه در نظر گرفت:

Requirement / User Story
↓
معیارهای پذیرش و سایر اطلاعات مرتبط
↓
سناریوهای تست
↓
تست کیس‌ها

البته این یک الگوی مفهومی است و در پروژه‌های واقعی ممکن است تیم‌ها فرآیند متفاوتی داشته باشند. در بعضی پروژه‌ها سناریوهای تست به‌صورت یک مستند مستقل ثبت می‌شوند و در بعضی دیگر تستر مستقیماً از نیازمندی‌ها و سایر منابع به طراحی تست کیس می‌رسد.

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

چه چیزی باید تست شود و آیا شرایط مهم آن را پوشش داده‌ایم؟

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

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

منابع

• ISTQB Glossary – Test Scenario
• ISTQB Certified Tester – Foundation Level
• ISTQB Glossary – Test Case
• ISTQB CTFL – Foundation Level

سؤالات متداول

سناریو تست چیست؟

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

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

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

آیا یک سناریو تست می‌تواند چند تست کیس داشته باشد؟

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

تفاوت سناریو تست و نیازمندی چیست؟

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

تفاوت سناریو تست و User Story چیست؟

User Story نیاز و هدف کاربر را بیان می‌کند، اما سناریو تست رفتارها و شرایطی را مشخص می‌کند که باید بررسی شوند. یک User Story می‌تواند به چند سناریوی تست منجر شود.

تفاوت سناریو تست و معیار پذیرش چیست؟

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

آیا سناریو تست فقط شامل شرایط مثبت است؟

خیر. سناریوهای تست باید در صورت نیاز شرایط مثبت، منفی، مسیرهای جایگزین، شرایط مرزی و خطاهای مهم را نیز پوشش دهند.

آیا همیشه باید سناریو تست را به‌صورت جداگانه مستند کنیم؟

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

چگونه سناریو تست خوب بنویسیم؟

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

آیا سناریو تست همان Test Scenario در همه تیم‌هاست؟

لزوماً نه. نحوه تعریف، سطح جزئیات و قالب مستندسازی سناریو تست ممکن است بین تیم‌ها و پروژه‌ها متفاوت باشد. بنابراین هنگام استفاده از این مفهوم باید روش کاری و تعاریف مورد استفاده در همان تیم را نیز در نظر گرفت.