Test Design چیست؟ راهنمای کامل طراحی تست در تست نرم‌افزار

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

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

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

بنابراین، Test Design فقط نوشتن تست‌کیس نیست؛ بلکه فرایندی برای تصمیم‌گیری درباره این است که چه تست‌هایی باید طراحی شوند تا رفتارها، شرایط مهم و ریسک‌های سیستم به شکل مؤثرتری پوشش داده شوند.

در این مقاله، Test Design را بر اساس مفاهیم و رویکرد ISTQB بررسی می‌کنیم و ارتباط آن را با مفاهیمی مانند Test Analysis، Test Condition، Test Case، Test Data، Test Technique و Test Coverage توضیح می‌دهیم. همچنین با استفاده از مثال‌های عملی نشان می‌دهیم چگونه می‌توان از یک Requirement به طراحی تست‌های مؤثر رسید.

۲. Test Design چیست؟

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

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

به زبان ساده، می‌توان گفت:

Test Design یعنی تبدیل اطلاعات و شرایط شناسایی‌شده در Test Analysis به طراحی تست‌های مشخص، قابل اجرا و هدفمند.

برای مثال، فرض کنید Requirement یک سیستم می‌گوید:

«کاربر باید بتواند فایلی با حجم حداکثر ۱۰ مگابایت آپلود کند.»

تستر در مرحله طراحی تست نباید فقط یک فایل ۵ مگابایتی انتخاب کند و Test Case بنویسد. باید شرایط مختلفی را در نظر بگیرد:

• فایل کمتر از ۱۰ مگابایت
• فایل دقیقاً ۱۰ مگابایت
• فایل بیشتر از ۱۰ مگابایت
• فایل خالی
• فایل با فرمت غیرمجاز
• فایل خراب یا غیرقابل پردازش

سپس بر اساس این شرایط، Test Case و Test Data مناسب طراحی می‌شوند.

بنابراین Test Design را می‌توان یک فعالیت مهم بین تحلیل نیازمندی‌ها و ایجاد تست‌های قابل اجرا در نظر گرفت:

Requirement / Test Basis
        ↓
Test Analysis
        ↓
Test Conditions
        ↓
Test Design
        ↓
Test Cases + Test Data

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

نکته مهم: Test Design با Test Technique یکسان نیست. تکنیک‌هایی مانند Equivalence Partitioning، Boundary Value Analysis و Decision Table Testing روش‌هایی هستند که می‌توانند در فرایند Test Design مورد استفاده قرار گیرند؛ اما خود Test Design مفهوم گسترده‌تری دارد و درباره تصمیم‌گیری و طراحی مجموعه تست‌های مناسب صحبت می‌کند.

۳. هدف از Test Design چیست؟

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

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

مهم‌ترین اهداف Test Design عبارت‌اند از:

۱. شناسایی شرایط مهم برای تست

تستر باید مشخص کند چه شرایطی می‌توانند بر رفتار سیستم تأثیر بگذارند.

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

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

۲. ایجاد پوشش مناسب

Test Design باید کمک کند رفتارها و شرایط مهم سیستم تا حد قابل‌قبولی پوشش داده شوند.

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

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

۳. کاهش تست‌های غیرضروری و تکراری

گاهی چند Test Case مختلف عملاً یک وضعیت یکسان را بررسی می‌کنند.

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

۴. توجه به ریسک‌های مهم

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

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

بنابراین Risk می‌تواند بر تصمیم‌های مربوط به Test Design تأثیر بگذارد و باعث شود تمرکز بیشتری روی بخش‌های مهم‌تر سیستم قرار گیرد.

۵. انتخاب Test Data مناسب

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

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

۶. استفاده مؤثر از Test Techniques

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

برای مثال ممکن است برای یک Requirement از:

• Equivalence Partitioning
• Boundary Value Analysis
• Decision Table Testing
• State Transition Testing
• Error Guessing

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

توضیح کامل این تکنیک‌ها در مقاله Test Technique انجام می‌شود و در این مقاله فقط نقش آن‌ها در Test Design را بررسی خواهیم کرد.

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

۴. Test Design در فرایند تست نرم‌افزار

برای درک بهتر Test Design، باید جایگاه آن را در فرایند کلی تست نرم‌افزار بشناسیم. در رویکرد ISTQB، طراحی تست یک فعالیت جدا و بدون ارتباط با سایر فعالیت‌های تست نیست؛ بلکه به فعالیت‌هایی مانند Test Analysis، Test Implementation و Test Execution وابسته است.

به‌صورت ساده، می‌توان ارتباط این فعالیت‌ها را این‌گونه نمایش داد:

Test Basis
    ↓
Test Analysis
    ↓
Test Conditions
    ↓
Test Design
    ↓
Test Cases + Test Data
    ↓
Test Implementation
    ↓
Test Execution

۴.۱. Test Basis؛ نقطه شروع

Test Basis اطلاعاتی است که تستر برای تعیین اینکه چه چیزی باید تست شود، از آن استفاده می‌کند.

بسته به پروژه، Test Basis می‌تواند شامل مواردی مانند موارد زیر باشد:

• Requirement
• User Story
• Acceptance Criteria
• SRS
• Business Rules
• Use Case
• مشخصات فنی و طراحی سیستم
• اطلاعات مرتبط با ریسک

بنابراین Test Design بدون داشتن اطلاعات مناسب درباره سیستم نمی‌تواند به شکل مؤثری انجام شود.

۴.۲. Test Analysis؛ چه چیزی باید تست شود؟

در Test Analysis، تستر Test Basis را بررسی می‌کند تا موارد قابل تست و شرایط مهم را شناسایی کند.

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

«کاربر باید بتواند فایلی با حجم حداکثر ۱۰ مگابایت آپلود کند.»

در Test Analysis ممکن است شرایطی مانند این موارد شناسایی شوند:

فایل کمتر از ۱۰ MB
فایل دقیقاً ۱۰ MB
فایل بیشتر از ۱۰ MB
فایل با فرمت نامعتبر
فایل خالی

این شرایط، مبنایی برای فعالیت‌های بعدی Test Design خواهند بود.

۴.۳. Test Design؛ چگونه تست را طراحی کنیم؟

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

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

• چه Test Caseهایی مورد نیاز هستند؟
• چه Test Dataهایی باید استفاده شوند؟
• چه شرایطی باید در تست پوشش داده شوند؟
• آیا نیاز به استفاده از یک یا چند Test Technique وجود دارد؟
• اولویت تست‌ها چگونه باشد؟
• آیا تست‌های طراحی‌شده پوشش مناسبی ایجاد می‌کنند؟

بنابراین Test Design پلی میان شرایط قابل تست و Test Caseهای قابل اجرا ایجاد می‌کند.

۴.۴. Test Implementation؛ آماده‌سازی تست برای اجرا

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

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

• آماده‌سازی محیط تست
• ایجاد یا آماده‌سازی Test Data
• مرتب‌سازی Test Caseها
• ایجاد Test Procedure
• آماده‌سازی تست‌های دستی یا خودکار

۴.۵. Test Execution؛ اجرای تست‌ها

در مرحله Test Execution، تست‌های آماده‌شده اجرا می‌شوند و نتایج واقعی با نتایج مورد انتظار مقایسه می‌شوند.

در صورت مشاهده رفتار غیرمنتظره، ممکن است یک Defect ثبت شود و اطلاعات حاصل از اجرای تست نیز می‌تواند برای اصلاح یا تکمیل Test Design مورد استفاده قرار گیرد.

یک نکته مهم درباره این جریان

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

در پروژه واقعی ممکن است در هنگام اجرای تست مشخص شود که:

• یک Requirement ابهام دارد؛
• یک Test Condition مهم در نظر گرفته نشده است؛
• Test Data کافی نیست؛
• یک Risk جدید شناسایی شده است؛
• یا Test Coverage کافی نیست.

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

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

۵. ورودی‌های Test Design چیست؟

برای طراحی تست مناسب، تستر به اطلاعاتی نیاز دارد که مشخص کند سیستم چه کاری باید انجام دهد، چه محدودیت‌هایی دارد و چه شرایطی ممکن است بر رفتار آن تأثیر بگذارد. این اطلاعات در چارچوب ISTQB می‌توانند بخشی از Test Basis باشند و مبنای فعالیت‌های Test Analysis و Test Design قرار گیرند.

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

مهم‌ترین ورودی‌های Test Design عبارت‌اند از:

۵.۱. Requirement

Requirement (نیازمندی) یکی از مهم‌ترین منابع طراحی تست است.

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

برای مثال:

«کاربر باید بتواند سفارشی بین ۱۰۰ هزار تا ۱۰ میلیون تومان ثبت کند.»

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

۵.۲. User Story

در پروژه‌های Agile، User Story می‌تواند یکی از منابع مهم Test Design باشد.

برای مثال:

«به‌عنوان یک کاربر، می‌خواهم بتوانم محصولات مورد علاقه‌ام را به Wishlist اضافه کنم.»

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

۵.۳. Acceptance Criteria

Acceptance Criteria (معیارهای پذیرش) جزئیات بیشتری درباره شرایطی که باید برای پذیرش یک قابلیت برقرار باشند ارائه می‌کنند.

برای مثال:

«محصول فقط زمانی می‌تواند به Wishlist اضافه شود که کاربر وارد حساب کاربری خود شده باشد.»

این معیار می‌تواند مستقیماً روی Test Design تأثیر بگذارد و شرایطی مانند کاربر واردشده و کاربر مهمان را ایجاد کند.

۵.۴. Specification و مستندات سیستم

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

• SRS
• FRD
• PRD
• BRD
• مستندات API
• مستندات معماری
• مشخصات رابط کاربری
• Business Rules

البته لازم نیست Test Design تمام این مستندات را به یک اندازه بررسی کند؛ میزان استفاده از هرکدام به نوع پروژه و قابلیت موردنظر بستگی دارد.

۵.۵. Use Case و جریان‌های کسب‌وکار

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

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

انتخاب محصول
      ↓
افزودن به سبد
      ↓
ثبت آدرس
      ↓
انتخاب روش ارسال
      ↓
پرداخت
      ↓
ثبت سفارش

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

۵.۶. Risk Information

اطلاعات مربوط به Risk نیز می‌تواند روی Test Design تأثیر بگذارد.

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

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

محاسبه مبلغ نهایی سفارش احتمالاً ریسک بیشتری نسبت به تغییر یک متن ساده در صفحه دارد.

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

۵.۷. اطلاعات مربوط به Defectهای قبلی

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

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

برای مثال، اگر در نسخه‌های قبلی سیستم چندین بار خطاهای مربوط به:

• محاسبه تخفیف
• موجودی کالا
• پرداخت
• تبدیل واحد پول

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

ارتباط ورودی‌ها با Test Design

Requirement
User Story
Acceptance Criteria
Specifications
Business Rules
Use Cases
Risk Information
Previous Defects
        ↓
   Test Analysis
        ↓
   Test Conditions
        ↓
    Test Design
        ↓
Test Cases + Test Data

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

در ادامه، یکی از مهم‌ترین مفاهیمی که در این فرایند باید بشناسیم را بررسی می‌کنیم: Test Condition؛ یعنی دقیقاً چه چیزی را می‌خواهیم تست کنیم.

۶. Test Condition چیست؟

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

در چارچوب ISTQB، Test Condition به یک جنبه یا ویژگی قابل تست از یک سیستم یا آیتم تست گفته می‌شود که می‌تواند با یک یا چند Test Case بررسی شود.

به زبان ساده:

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

یک مثال ساده

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

«کاربر باید بتواند با وارد کردن رمز عبور بین ۸ تا ۲۰ کاراکتر وارد حساب کاربری خود شود.»

این Requirement به‌تنهایی یک Test Case نیست. ابتدا باید شرایط مختلفی را که ارزش تست کردن دارند شناسایی کنیم.

Test Condition	توضیح
رمز کمتر از ۸ کاراکتر	بررسی رفتار سیستم در برابر مقدار کمتر از حد مجاز
رمز ۸ کاراکتری	بررسی حداقل مقدار مجاز
رمز بین ۸ تا ۲۰ کاراکتر	بررسی مقدار معتبر
رمز ۲۰ کاراکتری	بررسی حداکثر مقدار مجاز
رمز بیشتر از ۲۰ کاراکتر	بررسی مقدار بیشتر از حد مجاز
رمز خالی	بررسی نبود مقدار
رمز با فرمت نامعتبر	بررسی داده نامعتبر

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

Test Condition با Requirement چه تفاوتی دارد؟

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

برای مثال:

Requirement:
رمز عبور باید بین ۸ تا ۲۰ کاراکتر باشد.

می‌توان از این Requirement چند Test Condition استخراج کرد:

Requirement
"Password must be 8–20 characters"
          ↓
Test Conditions
          ├── کمتر از 8
          ├── برابر 8
          ├── بین 8 و 20
          ├── برابر 20
          └── بیشتر از 20

بنابراین یک Requirement می‌تواند به چند Test Condition منجر شود.

Test Condition با Test Case چه تفاوتی دارد؟

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

مثلاً:

Test Condition:

بررسی رفتار سیستم در برابر رمز عبور کمتر از حداقل مجاز.

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

Test Data: Test123
Precondition: صفحه Login باز است
Step: وارد کردن Username
Step: وارد کردن Password
Step: کلیک روی Login
Expected Result: نمایش پیام خطا

پس:

Test Condition یک مفهوم سطح بالاتر از Test Case است و می‌تواند مبنای ایجاد یک یا چند Test Case قرار گیرد.

چرا شناسایی Test Condition مهم است؟

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

برای مثال، اگر فقط این Test Case را بنویسیم:

ورود با Username و Password معتبر

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

• Password اشتباه
• Username اشتباه
• Password خالی
• Username خالی
• Account قفل‌شده
• کاربر غیرفعال
• تعداد تلاش ناموفق بیشتر از حد مجاز

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

Test Condition و Test Design

Test Basis
    ↓
Test Analysis
    ↓
Identify Test Conditions
    ↓
Test Design
    ↓
Test Cases
    ↓
Test Execution

در نتیجه، Test Condition یکی از نقاط اتصال مهم بین Test Analysis و Test Design است و شناسایی دقیق آن کمک می‌کند Test Caseها بر اساس شرایط واقعی و مهم سیستم طراحی شوند، نه صرفاً بر اساس چند سناریوی اولیه.

۷. چگونه Requirement را به Test Condition تبدیل کنیم؟

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

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

مرحله ۱: Requirement را به بخش‌های قابل تست تقسیم کنید

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

برای مثال:

«کاربر باید بتواند فایلی با فرمت PDF و حجم حداکثر ۱۰ مگابایت آپلود کند.»

در این Requirement حداقل دو قانون مهم وجود دارد:

• فرمت فایل باید PDF باشد.
• حجم فایل نباید بیشتر از ۱۰ مگابایت باشد.

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

مرحله ۲: قوانین و محدودیت‌ها را شناسایی کنید

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

File Format → PDF
Maximum Size → 10 MB

هر محدودیت می‌تواند یک یا چند Test Condition ایجاد کند.

مرحله ۳: حالت‌های معتبر و نامعتبر را در نظر بگیرید

فقط حالت موفق را بررسی نکنید.

برای مثال درباره فرمت فایل:

PDF              → معتبر
JPG              → نامعتبر
PNG              → نامعتبر
DOCX             → نامعتبر

و درباره حجم فایل:

کمتر از 10 MB    → معتبر
10 MB             → معتبر
بیشتر از 10 MB   → نامعتبر

به این ترتیب، Test Conditionهای بیشتری شناسایی می‌شوند.

مرحله ۴: شرایط مرزی را پیدا کنید

اگر Requirement دارای یک محدوده یا مقدار مشخص باشد، باید به Boundaryها توجه کنیم.

در مثال بالا:

حداکثر حجم فایل = ۱۰ مگابایت

بنابراین شرایطی مانند:

9.9 MB
10 MB
10.1 MB

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

در این مرحله هنوز لازم نیست تکنیک Boundary Value Analysis را به‌صورت کامل اجرا کنیم؛ هدف فعلی فقط شناسایی شرایطی است که ارزش تست کردن دارند.

مرحله ۵: شرایط خطا و Exception را بررسی کنید

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

تستر باید بررسی کند در شرایط غیرعادی چه رفتارهایی ممکن است اهمیت داشته باشند.

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

البته همه این موارد الزاماً Test Condition نهایی نیستند؛ باید با توجه به Requirement، Risk و رفتار مورد انتظار سیستم تصمیم گرفت کدام موارد ارزش تست دارند.

مرحله ۶: Test Conditionها را مستقل از Test Case نگه دارید

در این مرحله هنوز نباید وارد جزئیات Stepها شویم.

برای مثال:

Test Condition:

بررسی آپلود فایل PDF با حجم بیشتر از حد مجاز.

نه اینکه بلافاصله بنویسیم:

وارد صفحه Upload شوید → روی Choose File کلیک کنید → فایل X را انتخاب کنید → روی Upload کلیک کنید…

این جزئیات مربوط به Test Case است.

یک مثال کامل

فرض کنید Requirement زیر را داریم:

«کاربر باید بتواند سفارشی بین ۱۰۰ هزار تا ۱۰ میلیون تومان ثبت کند.»

ابتدا محدودیت را استخراج می‌کنیم:

Minimum = 100,000
Maximum = 10,000,000

سپس Test Conditionهای احتمالی را شناسایی می‌کنیم:

Test Condition	وضعیت
مبلغ کمتر از ۱۰۰ هزار تومان	نامعتبر
مبلغ دقیقاً ۱۰۰ هزار تومان	معتبر
مبلغ بین حداقل و حداکثر	معتبر
مبلغ دقیقاً ۱۰ میلیون تومان	معتبر
مبلغ بیشتر از ۱۰ میلیون تومان	نامعتبر
مبلغ صفر	نامعتبر
مبلغ منفی	نامعتبر
مبلغ خالی	نامعتبر

حالا می‌توانیم از این Test Conditionها برای Test Design و سپس ایجاد Test Caseهای مناسب استفاده کنیم.

یک نکته مهم

تبدیل Requirement به Test Condition یک فرمول ثابت و مکانیکی ندارد. تستر باید علاوه بر متن Requirement، به Risk، Business Rules، نوع سیستم، تجربه قبلی و Test Basis موجود نیز توجه کند.

به همین دلیل، دو تستر ممکن است برای یک Requirement، Test Conditionهای متفاوتی پیشنهاد کنند؛ اما Test Design مناسب باید بتواند شرایط مهم و قابل‌توجیه را با توجه به هدف تست و ریسک‌های سیستم پوشش دهد.

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

۸. شناسایی شرایط و حالت‌های قابل تست

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

در Test Design، یکی از اشتباهات رایج این است که تستر فقط مسیر اصلی و موفق سیستم را بررسی کند. در حالی که بسیاری از Defectها در شرایطی رخ می‌دهند که ورودی نامعتبر است، سیستم در وضعیت غیرعادی قرار دارد یا کاربر از مسیر مورد انتظار خارج می‌شود.

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

۸.۱. شرایط مثبت (Positive Conditions)

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

برای مثال، اگر کاربر باید رمز عبوری بین ۸ تا ۲۰ کاراکتر وارد کند:

Password = Test1234

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

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

۸.۲. شرایط منفی (Negative Conditions)

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

مثلاً:

Password = Test

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

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

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

هدف Negative Testing این نیست که سیستم را صرفاً با داده‌های عجیب امتحان کنیم؛ بلکه باید بررسی کنیم سیستم در برابر شرایط نامعتبر، رفتار کنترل‌شده و مورد انتظار دارد.

۸.۳. شرایط مرزی (Boundary Conditions)

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

فرض کنید سن مجاز برای ثبت‌نام بین ۱۸ تا ۶۰ سال است.

17  → کمتر از حداقل
18  → حداقل
19  → نزدیک به حداقل
59  → نزدیک به حداکثر
60  → حداکثر
61  → بیشتر از حداکثر

در اینجا هدف شناسایی شرایط مرزی مهم است. تکنیک Boundary Value Analysis می‌تواند برای طراحی سیستماتیک تست‌ها در چنین شرایطی مورد استفاده قرار گیرد.

۸.۴. شرایط خالی و ناقص

نباید فقط داده‌های کامل را در نظر گرفت.

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

Username = خالی
Password = خالی
Email = خالی

همچنین ترکیب‌هایی مانند:

Username = مقدار معتبر
Password = خالی

نیز ممکن است اهمیت داشته باشند.

این موارد به‌خصوص برای فرم‌ها، APIها و ورودی‌های کاربر اهمیت زیادی دارند.

۸.۵. حالت‌های مختلف سیستم

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

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

“`html

Pending
   ↓
Paid
   ↓
Processing
   ↓
Shipped
   ↓
Delivered

تستر باید بررسی کند آیا عملیات موردنظر در هر وضعیت مجاز است یا خیر.

برای مثال:

آیا می‌توان سفارش Delivered را دوباره لغو کرد؟

این نوع شرایط می‌تواند در Test Design شناسایی شود و در صورت نیاز با استفاده از State Transition Testing طراحی تست شود.

۸.۶. نقش‌ها و مجوزهای مختلف

گاهی یک Feature برای کاربران مختلف رفتار متفاوتی دارد.

Guest
Customer
Admin

ممکن است:

• Guest فقط بتواند محصولات را مشاهده کند.
• Customer بتواند سفارش ثبت کند.
• Admin بتواند محصول جدید ایجاد کند.

بنابراین User Role و Permission نیز می‌توانند شرایط مهمی برای Test Design باشند.

۸.۷. شرایط وابسته به سیستم یا محیط

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

برای مثال در یک سیستم پرداخت:

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

این موارد نشان می‌دهند که Test Design فقط به ورودی‌های مستقیم کاربر محدود نمی‌شود و شرایط محیطی و وابستگی‌های سیستم نیز می‌توانند در طراحی تست اهمیت داشته باشند.

یک چارچوب ساده برای شناسایی شرایط قابل تست

آیا مسیر موفق را بررسی کرده‌ام؟
        ↓
آیا شرایط نامعتبر را بررسی کرده‌ام؟
        ↓
آیا Boundaryها را شناسایی کرده‌ام؟
        ↓
آیا داده‌های خالی یا ناقص را بررسی کرده‌ام؟
        ↓
آیا Stateهای مختلف سیستم را در نظر گرفته‌ام؟
        ↓
آیا Role و Permissionهای مختلف مهم هستند؟
        ↓
آیا شرایط خطا و وابستگی‌های خارجی مهم هستند؟
        ↓
آیا Riskهای مهم پوشش داده شده‌اند؟

البته قرار نیست تمام این موارد برای هر Feature بررسی شوند. انتخاب شرایط مناسب باید بر اساس Requirement، هدف تست، Risk و ماهیت Feature انجام شود.

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

۹. Test Data Design چیست؟

پس از شناسایی Test Conditionها، یکی از موضوعات مهم در Test Design این است که مشخص کنیم برای بررسی این شرایط به چه داده‌هایی نیاز داریم. این بخش با مفهوم Test Data Design مرتبط است.

Test Data (داده تست) داده‌ای است که برای اجرای یک تست استفاده می‌شود تا یک Test Condition یا رفتار مشخص سیستم را بررسی کنیم.

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

«سن کاربر باید بین ۱۸ تا ۶۰ سال باشد.»

صرفاً مشخص کردن این Test Condition کافی نیست. باید داده‌هایی انتخاب کنیم که بتوانند شرایط مختلف را فعال کنند:

“`html

17  → کمتر از حد مجاز
18  → حداقل مقدار مجاز
30  → مقدار معتبر
60  → حداکثر مقدار مجاز
61  → بیشتر از حد مجاز

بنابراین Test Data باید به‌گونه‌ای انتخاب شود که شرایط موردنظر Test Design را به‌درستی ایجاد کند.

انواع Test Data

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

Valid Test Data

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

Age = 30

اگر محدوده مجاز ۱۸ تا ۶۰ باشد، این داده معتبر است.

Invalid Test Data

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

Age = 70

در صورتی که حداکثر سن مجاز ۶۰ سال باشد.

Boundary Test Data

داده‌هایی که در اطراف مرزهای تعریف‌شده قرار دارند.

17
18
60
61

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

Empty یا Missing Data

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

Username = ""

این نوع داده در فرم‌ها و APIها اهمیت زیادی دارد.

Special یا Unexpected Data

گاهی لازم است داده‌هایی بررسی شوند که احتمال ایجاد رفتار غیرمنتظره در سیستم دارند؛ مانند:

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

البته انتخاب این داده‌ها باید متناسب با Requirement، Risk و هدف تست باشد.

انتخاب Test Data بر اساس Test Condition

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

برای مثال فرض کنید Requirement می‌گوید:

«کاربر می‌تواند نام کاربری بین ۵ تا ۲۰ کاراکتر انتخاب کند.»

Test Conditionها:

کمتر از 5
برابر 5
بین 5 و 20
برابر 20
بیشتر از 20
خالی

سپس Test Data مناسب برای این شرایط انتخاب می‌کنیم:

Test Condition	Test Data نمونه
کمتر از ۵	Ali
برابر ۵	Ali12
مقدار معتبر	Mehrdad123
برابر ۲۰	رشته ۲۰ کاراکتری
بیشتر از ۲۰	رشته ۲۱ کاراکتری
خالی	""

در اینجا می‌بینیم که Test Condition مشخص می‌کند چه شرایطی باید بررسی شوند و Test Data کمک می‌کند آن شرایط را در اجرای واقعی ایجاد کنیم.

Test Data در API و سیستم‌های پیچیده‌تر

Test Data فقط به فرم‌های UI محدود نیست.

در API Testing، برای مثال ممکن است داده‌هایی مانند این موارد لازم باشند:

Valid Request
Invalid Request
Missing Parameter
Null Value
Boundary Value
Invalid Token
Expired Token
Duplicate Request

در سیستم‌های پیچیده‌تر نیز ممکن است Test Data شامل مواردی مانند:

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

Test Data خوب چه ویژگی‌هایی دارد؟

داده‌های تست مناسب باید:

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

در پروژه‌های واقعی، مدیریت Test Data می‌تواند به یک موضوع مستقل و نسبتاً پیچیده تبدیل شود؛ به‌خصوص در سیستم‌هایی که داده‌های زیادی دارند یا بین چند سرویس وابستگی وجود دارد.

بنابراین در Test Design هدف این نیست که حجم زیادی از داده ایجاد کنیم؛ هدف این است که داده‌های مناسب و معناداری برای ایجاد و بررسی Test Conditionهای موردنظر انتخاب کنیم.

۱۰. طراحی تست‌های مثبت و منفی (Positive و Negative Tests)

یکی از تصمیم‌های مهم در Test Design این است که مشخص کنیم سیستم فقط در شرایط معتبر بررسی شود یا شرایط نامعتبر و غیرمنتظره نیز مورد آزمایش قرار گیرند.

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

تست مثبت (Positive Testing)

در Positive Testing، سیستم با داده‌ها و شرایط معتبر بررسی می‌شود تا مشخص شود آیا رفتار مورد انتظار را ارائه می‌دهد یا خیر.

برای مثال، فرض کنید Requirement سیستم این باشد:

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

یک Test Condition می‌تواند این باشد:

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

و Test Data می‌تواند شامل موارد زیر باشد:

Email: user@example.com
Password: ValidPass123

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

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

تست منفی (Negative Testing)

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

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

شرایط	نمونه
رمز عبور اشتباه	WrongPass123
ایمیل نامعتبر	user@
ایمیل خالی	""
رمز عبور خالی	""
هر دو فیلد خالی	"" / ""
کاربر وجود ندارد	ایمیل ثبت‌نشده
حساب مسدود است	کاربر Locked

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

برای مثال، ممکن است انتظار داشته باشیم:

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

آیا هر ورودی نامعتبر باید یک Test Case داشته باشد؟

خیر.

این نکته در Test Design اهمیت زیادی دارد.

فرض کنید یک فیلد می‌تواند صدها نوع ورودی نامعتبر دریافت کند. قرار نیست تستر برای تک‌تک حالت‌های قابل تصور یک Test Case ایجاد کند.

انتخاب شرایط باید بر اساس عواملی مانند:

• Requirement
• Business Rule
• Risk
• اهمیت Feature
• احتمال وقوع خطا
• رفتار مورد انتظار سیستم
• Test Technique مناسب

انجام شود.

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

4 کاراکتر  → کمتر از حد مجاز
5 کاراکتر  → حداقل مجاز
10 کاراکتر → مقدار معتبر
20 کاراکتر → حداکثر مجاز
21 کاراکتر → بیشتر از حد مجاز

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

Positive و Negative فقط مربوط به Input نیستند

یک اشتباه رایج این است که Positive و Negative Testing را فقط به ورودی‌های معتبر و نامعتبر محدود کنیم.

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

برای مثال:

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

در اینجا:

Positive Condition:

Order Status = Pending
Action = Cancel

Negative Condition:

Order Status = Delivered
Action = Cancel

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

ارتباط Positive و Negative Testing با Test Design

در Test Design می‌توان برای هر Feature این سؤال ساده را مطرح کرد:

«اگر کاربر یا سیستم شرایط مورد انتظار را داشته باشد چه اتفاقی باید بیفتد، و اگر یکی از شرایط مورد انتظار برقرار نباشد چه اتفاقی باید بیفتد؟»

پاسخ به این سؤال کمک می‌کند Test Conditionهای مثبت و منفی شناسایی شوند.

در نهایت، یک طراحی تست خوب فقط ثابت نمی‌کند که:

«سیستم در شرایط صحیح کار می‌کند.»

بلکه بررسی می‌کند:

«سیستم در برابر شرایط نامعتبر، غیرمجاز و خطا نیز رفتار مورد انتظار را دارد.»

این موضوع یکی از دلایل اصلی اهمیت Negative Testing در Test Design است.

۱۱. نقش Boundary و Edge Case در Test Design

یکی از بخش‌های مهم در Test Design، توجه به شرایطی است که در نزدیکی محدوده‌ها یا در حالت‌های غیرمعمول سیستم قرار دارند. این شرایط معمولاً با دو مفهوم Boundary Condition و Edge Case شناخته می‌شوند.

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

Boundary چیست؟

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

برای مثال، فرض کنید یک سیستم اجازه ثبت سفارش‌هایی با مبلغ بین ۱۰۰ هزار تا ۱۰ میلیون تومان را می‌دهد.

99,999      → کمتر از حداقل
100,000     → حداقل مجاز
100,001     → بالاتر از حداقل
9,999,999   → پایین‌تر از حداکثر
10,000,000  → حداکثر مجاز
10,000,001  → بیشتر از حداکثر

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

Edge Case چیست؟

Edge Case به شرایطی گفته می‌شود که معمولاً در لبه‌های رفتار مورد انتظار سیستم یا در شرایط غیرمعمول رخ می‌دهند.

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

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

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

تفاوت Boundary و Edge Case

مفهوم	تمرکز اصلی
Boundary	مرزهای مشخص و تعریف‌شده در قوانین یا محدوده‌ها
Edge Case	شرایط خاص، غیرمعمول یا نزدیک به لبه رفتار سیستم

برای مثال:

حداکثر تعداد محصولات در سبد خرید ۲۰ عدد است.

بررسی 20 و 21 مستقیماً به Boundary مربوط می‌شود.

اما بررسی حالتی مانند:

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

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

آیا Boundary و Edge Case همیشه باید تست شوند؟

خیر.

این نکته در Test Design بسیار مهم است.

وجود یک Edge Case به این معنی نیست که حتماً باید برای آن Test Case ایجاد شود. تستر باید بر اساس Requirement، Risk، اهمیت Feature و احتمال وقوع شرایط تصمیم بگیرد.

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

بنابراین هدف Test Design این نیست که تمام حالت‌های ممکن را بررسی کند؛ بلکه باید مهم‌ترین و ارزشمندترین شرایط را شناسایی کند.

ارتباط Boundary با Test Technique

برای طراحی تست در اطراف مرزها، یکی از تکنیک‌های مهم Boundary Value Analysis (BVA) است.

برای مثال، اگر محدوده مجاز ۱۸ تا ۶۰ باشد، BVA می‌تواند به تست مقادیر نزدیک به مرزها کمک کند.

اما باید توجه داشت که:

Boundary در Test Design یک نوع شرایط مهم برای شناسایی است، در حالی که Boundary Value Analysis یک Test Technique برای طراحی سیستماتیک تست‌های مرتبط با این شرایط است.

بنابراین Test Design از وجود Boundary آگاه می‌شود و سپس می‌تواند از BVA برای طراحی تست‌های مناسب استفاده کند.

یک مثال کامل‌تر

فرض کنید یک فروشگاه اینترنتی این قانون را دارد:

«کاربر می‌تواند حداکثر ۵ عدد از یک محصول را به سبد خرید اضافه کند.»

در Test Design می‌توان شرایط زیر را شناسایی کرد:

0 عدد
1 عدد
4 عدد
5 عدد
6 عدد

اما ممکن است شرایط دیگری نیز اهمیت داشته باشند:

تعداد منفی
مقدار خالی
مقدار اعشاری
مقدار بسیار بزرگ
موجودی کمتر از تعداد درخواستی

در اینجا Test Design ابتدا شرایط مهم را شناسایی می‌کند و سپس Test Technique مناسب می‌تواند به انتخاب سیستماتیک Test Data و Test Caseها کمک کند.

چرا توجه به Boundary و Edge Case مهم است؟

توجه به این شرایط می‌تواند کمک کند:

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

در نتیجه، Boundary و Edge Case بخشی از تفکر طراحی تست هستند، نه اینکه صرفاً فهرستی از Test Caseهای اضافی باشند. Test Design باید تشخیص دهد کدام مرزها و شرایط خاص ارزش بررسی دارند و سپس با استفاده از تکنیک مناسب، تست‌های مؤثر برای آن‌ها طراحی شود.

۱۲. Test Design مبتنی بر Risk

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

اینجاست که Risk-Based Test Design اهمیت پیدا می‌کند.

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

Risk در Test Design چیست؟

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

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

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

چگونه Risk روی Test Design تأثیر می‌گذارد؟

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

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

در این شرایط، Test Design باید برای قابلیت‌های پرریسک، شرایط و حالت‌های بیشتری را در نظر بگیرد.

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

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

در حالی که برای یک Feature کم‌ریسک ممکن است چنین سطحی از جزئیات ضروری نباشد.

Risk فقط به اهمیت Business محدود نیست

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

برای مثال:

• کدی که اخیراً تغییر زیادی کرده است.
• بخشی که قبلاً Defectهای زیادی داشته است.
• Featureای که به چند سیستم خارجی وابسته است.
• بخشی که منطق پیچیده‌ای دارد.
• قابلیت جدیدی که هنوز به اندازه کافی تست نشده است.

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

Business Impact + Technical Complexity + Change + Defect History + Dependencies

اولویت‌بندی Test Design

فرض کنید برای یک Feature ده‌ها Test Condition شناسایی کرده‌ایم. همه آن‌ها الزاماً ارزش یکسانی ندارند.

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

High Risk
   ↓
اولویت بالاتر در طراحی و اجرای تست

Medium Risk
   ↓
اولویت متوسط

Low Risk
   ↓
اولویت پایین‌تر

برای مثال، در سیستم پرداخت:

«پرداخت موفق با مبلغ معتبر»

ممکن است یک شرایط High Priority باشد.

اما:

«نمایش صحیح یک پیام کم‌اهمیت در یک حالت بسیار نادر»

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

Risk-Based Testing به معنی حذف تست‌های کم‌ریسک نیست

این نکته مهم است.

Risk-Based Test Design به این معنی نیست که تستر تمام موارد Low Risk را حذف کند.

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

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

یک مثال عملی

فرض کنید در یک فروشگاه اینترنتی، Feature پرداخت شامل این Test Conditionها باشد:

Test Condition	Risk	اولویت
پرداخت موفق	بسیار زیاد	بسیار بالا
پرداخت با کارت نامعتبر	زیاد	بالا
قطع ارتباط با درگاه	بسیار زیاد	بسیار بالا
دوبار کلیک کردن روی پرداخت	بسیار زیاد	بسیار بالا
Timeout درگاه	زیاد	بالا
مبلغ صفر	زیاد	بالا
نمایش پیام موفقیت	متوسط	متوسط
ظاهر دکمه پرداخت	کم	پایین

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

ارتباط Risk با Test Coverage

Risk همچنین می‌تواند روی Test Coverage تأثیر بگذارد.

برای یک Feature پرریسک ممکن است بخواهیم:

• Test Conditionهای بیشتری شناسایی کنیم.
• Positive و Negative Tests بیشتری داشته باشیم.
• Boundaryها را دقیق‌تر بررسی کنیم.
• Stateهای بیشتری را پوشش دهیم.
• Test Data متنوع‌تری ایجاد کنیم.
• چند Test Technique را ترکیب کنیم.

در نتیجه، Coverage مناسب برای همه قسمت‌های سیستم الزاماً یکسان نیست.

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

در نهایت، Risk-Based Test Design به تستر کمک می‌کند از یک سؤال ساده فراتر برود:

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

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

«کدام چیزها بیشترین اهمیت و ریسک را دارند و باید با چه عمقی طراحی و تست شوند؟»

۱۳. Test Coverage در Test Design

یکی از اهداف اصلی Test Design این است که مطمئن شویم شرایط مهم و رفتارهای قابل‌تست سیستم به اندازه کافی پوشش داده شده‌اند.

در اینجا مفهوم Test Coverage اهمیت پیدا می‌کند.

به زبان ساده، Test Coverage نشان می‌دهد چه مقدار از موارد موردنظر برای تست، توسط تست‌ها پوشش داده شده‌اند.

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

چرا Coverage در Test Design مهم است؟

فرض کنید برای یک قابلیت، ۲۰ Test Case طراحی کرده‌ایم.

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

ممکن است هر ۲۰ تست تقریباً یک مسیر یکسان را بررسی کنند و در مقابل، چند حالت مهم سیستم اصلاً تست نشده باشند.

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

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

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

آیا Test Caseهای طراحی‌شده واقعاً شرایط مهم سیستم را پوشش می‌دهند؟

Coverage در Test Design چه چیزهایی را می‌تواند پوشش دهد؟

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

۱. Requirement Coverage

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

Requirement 1 → Covered
Requirement 2 → Covered
Requirement 3 → Not Covered

این نوع Coverage کمک می‌کند Requirementای وجود نداشته باشد که هیچ تستی برای آن طراحی نشده باشد.

۲. Test Condition Coverage

در این حالت بررسی می‌کنیم Test Conditionهای شناسایی‌شده تا چه اندازه توسط Test Caseها پوشش داده شده‌اند.

مثلاً اگر برای یک فیلد شرایط زیر را شناسایی کرده باشیم:

Valid
Invalid
Empty
Boundary
Out of Range

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

۳. Risk Coverage

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

High Risk   → Covered
High Risk   → Covered
Medium Risk → Covered
Low Risk    → Not Covered

ممکن است چنین وضعیتی کاملاً قابل قبول باشد؛ زیرا منابع تست محدود هستند و تمرکز روی Riskهای مهم‌تر قرار گرفته است.

Coverage نباید به یک عدد تبدیل شود

یکی از برداشت‌های اشتباه این است که مثلاً:

«ما ۹۰٪ Coverage داریم، پس سیستم تقریباً به‌طور کامل تست شده است.»

اما باید پرسید:

۹۰٪ چه چیزی؟

ممکن است ۹۰٪ Requirementها پوشش داده شده باشند، اما یک Requirement بسیار مهم مربوط به پرداخت اصلاً تست نشده باشد.

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

Coverage و Test Design

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

برای مثال، فرض کنید Test Design برای یک Feature این Test Conditionها را شناسایی کرده است:

A → شرایط معتبر
B → شرایط نامعتبر
C → Boundary
D → Error Condition
E → Permission
F → State مختلف

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

A → Test Case دارد ✓
B → Test Case دارد ✓
C → Test Case دارد ✓
D → Test Case ندارد ✗
E → Test Case دارد ✓
F → Test Case ندارد ✗

در اینجا Test Design می‌تواند قبل از اجرای تست نشان دهد که دو Test Condition مهم هنوز پوشش داده نشده‌اند.

Coverage و Test Technique

Test Techniqueها نیز می‌توانند به ایجاد Coverage بهتر کمک کنند.

• Equivalence Partitioning → پوشش کلاس‌های مختلف داده
• Boundary Value Analysis → پوشش مرزهای مهم
• Decision Table Testing → پوشش ترکیب شرایط و قوانین
• State Transition Testing → پوشش Stateها و Transitionها

بنابراین Test Technique ابزارهایی هستند که به تستر کمک می‌کنند Coverage موردنظر را به شکل سیستماتیک‌تری ایجاد کند.

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

استفاده از یک Test Technique به‌تنهایی تضمین نمی‌کند که Coverage مناسبی ایجاد شده است.

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

Coverage خوب چه ویژگی‌ای دارد؟

Coverage مناسب باید:

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

بنابراین در Test Design، هدف این نیست که همیشه به بیشترین Coverage ممکن برسیم.

هدف این است که:

با توجه به هدف تست، Risk و منابع موجود، Coverage کافی و معناداری ایجاد کنیم.

این دیدگاه باعث می‌شود Test Design از «تولید تعداد زیادی Test Case» فاصله بگیرد و به سمت طراحی تست‌های هدفمند و قابل دفاع حرکت کند.

۱۴. نقش Test Technique در Test Design

در بخش‌های قبل دیدیم که Test Design با شناسایی Test Condition، انتخاب Test Data، بررسی شرایط مثبت و منفی، Boundaryها، Risk و Coverage سروکار دارد. اما یک سؤال مهم باقی می‌ماند:

چگونه برای یک Test Condition، تست‌های مناسب و کافی طراحی کنیم؟

اینجاست که Test Technique وارد می‌شود.

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

به بیان ساده:

Test Design مشخص می‌کند چه چیزی باید طراحی و پوشش داده شود؛ Test Technique کمک می‌کند این تست‌ها چگونه به شکل مؤثرتری طراحی شوند.

یک مثال ساده

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

«مبلغ سفارش باید بین ۱۰۰ هزار تا ۱۰ میلیون تومان باشد.»

در Test Design، تستر ممکن است شرایط زیر را شناسایی کند:

کمتر از حداقل
حداقل مقدار
مقدار معتبر
حداکثر مقدار
بیشتر از حداکثر

حالا برای طراحی سیستماتیک Test Data می‌توان از Boundary Value Analysis استفاده کرد:

99,999
100,000
100,001
9,999,999
10,000,000
10,000,001

• Test Design → مشخص می‌کند Boundaryها مهم هستند و باید پوشش داده شوند.
• Test Technique → کمک می‌کند مقادیر مناسب اطراف Boundaryها به شکل سیستماتیک انتخاب شوند.

Test Technique فقط برای Boundary نیست

بسته به ماهیت Requirement و Test Condition، تکنیک‌های مختلفی می‌توانند در Test Design استفاده شوند.

نوع شرایط	تکنیک مناسب
محدوده‌های ورودی	Boundary Value Analysis
گروه‌های مختلف داده	Equivalence Partitioning
ترکیب چند شرط	Decision Table Testing
تغییر وضعیت سیستم	State Transition Testing
رفتارهای مبتنی بر سناریو	Use Case Testing
پیدا کردن خطاهای محتمل	Error Guessing
بررسی اکتشافی سیستم	Exploratory Testing

این تکنیک‌ها قرار نیست جای Test Design را بگیرند؛ بلکه ابزارهایی در فرایند طراحی تست هستند.

آیا برای هر Test Condition باید یک Test Technique انتخاب کنیم؟

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

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

• Equivalence Partitioning برای دسته‌بندی مبالغ
• Boundary Value Analysis برای محدودیت مبلغ
• Decision Table Testing برای ترکیب شرایط حساب و تراکنش
• State Transition Testing برای بررسی وضعیت‌های مختلف تراکنش

بنابراین انتخاب تکنیک باید بر اساس ماهیت Test Condition، هدف تست و Risk انجام شود.

یک Test Design می‌تواند چند Test Technique داشته باشد

فرض کنید یک Requirement داریم:

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

در اینجا چند عامل مهم وجود دارد:

Order Status
User Permission
Cancellation Request

• State Transition Testing می‌تواند برای بررسی وضعیت‌های مختلف سفارش استفاده شود.
• Decision Table Testing می‌تواند برای بررسی ترکیب وضعیت سفارش و مجوز کاربر به کار رود.

بنابراین یک Requirement می‌تواند به چند Test Condition منجر شود و هر Test Condition نیز ممکن است با یک یا چند Test Technique بررسی شود.

Test Technique و Test Case چه تفاوتی دارند؟

این تفاوت برای جلوگیری از اشتباه مفهومی بسیار مهم است.

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

• Test Technique: Boundary Value Analysis
• Test Condition: بررسی تعداد محصولات در اطراف حداکثر مقدار مجاز
• Test Data: 4، 5 و 6
• Test Case: بررسی رفتار سیستم زمانی که تعداد محصول روی ۶ قرار می‌گیرد.

Test Technique
       ↓
Test Design
       ↓
Test Condition + Test Data
       ↓
Test Case

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

انتخاب Test Technique مناسب

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

1. چه چیزی را می‌خواهیم پوشش دهیم؟
2. نوع Test Condition چیست؟
3. آیا Boundary یا Range داریم؟
4. آیا چند شرط با یکدیگر ترکیب می‌شوند؟
5. آیا رفتار سیستم به State وابسته است؟
6. آیا Requirement به سناریو یا Use Case مرتبط است؟
7. آیا Risk یا تجربه قبلی نشان می‌دهد خطاهای خاصی محتمل هستند؟

پاسخ به این سؤال‌ها کمک می‌کند Test Technique مناسب انتخاب شود.

در نتیجه، Test Technique بخشی از جعبه‌ابزار Test Designer است، نه خود Test Design. یک تستر خوب ابتدا شرایط مهم را شناسایی می‌کند و سپس با توجه به ماهیت آن شرایط و Risk موجود، تکنیک مناسب را برای طراحی تست انتخاب می‌کند.

۱۵. ترکیب چند Test Technique در طراحی تست

در پروژه‌های واقعی، معمولاً یک Test Technique به‌تنهایی نمی‌تواند تمام جنبه‌های یک Feature را پوشش دهد. یک Requirement ممکن است هم محدودیت مقداری داشته باشد، هم به چند شرط وابسته باشد و هم رفتار سیستم در Stateهای مختلف تغییر کند.

در چنین شرایطی، می‌توان چند Test Technique را در یک Test Design ترکیب کرد.

چرا ترکیب Test Techniqueها اهمیت دارد؟

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

«کد تخفیف فقط برای سفارش‌های بالاتر از ۵۰۰ هزار تومان و فقط برای کاربران دارای حساب کاربری معتبر قابل استفاده است.»

در این Requirement چند موضوع مختلف وجود دارد:

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

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

استفاده از Equivalence Partitioning

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

کمتر از ۵۰۰ هزار
۵۰۰ هزار و بیشتر

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

استفاده از Boundary Value Analysis

از آنجا که مبلغ ۵۰۰ هزار تومان یک Boundary است، می‌توان شرایط نزدیک به آن را نیز بررسی کرد:

499,999
500,000
500,001

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

استفاده از Decision Table Testing

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

مبلغ کافی	کاربر معتبر	کد تخفیف معتبر	نتیجه
بله	بله	بله	تخفیف اعمال شود
بله	بله	خیر	تخفیف اعمال نشود
بله	خیر	بله	تخفیف اعمال نشود
خیر	بله	بله	تخفیف اعمال نشود

در اینجا Decision Table Testing به بررسی ترکیب شرایط کمک می‌کند.

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

Requirement
     ↓
Test Conditions
     ↓
┌──────────────────────────────┐
│ مبلغ سفارش                  │
│ وضعیت کاربر                 │
│ اعتبار کد تخفیف              │
└──────────────────────────────┘
     ↓
Test Techniques
     ↓
EP + BVA + Decision Table
     ↓
Test Cases + Test Data

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

آیا ترکیب تکنیک‌ها یعنی باید Test Caseهای بیشتری ایجاد کنیم؟

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

ممکن است با ترکیب مناسب چند تکنیک، بتوانیم با تعداد محدودی Test Case، شرایط مهم بیشتری را پوشش دهیم. برای مثال، اگر یک Test Case هم یک Boundary مهم را پوشش دهد و هم یکی از ترکیب‌های مهم Decision Table را بررسی کند، می‌تواند ارزش بیشتری نسبت به چند Test Case مشابه داشته باشد.

بنابراین هنگام ترکیب تکنیک‌ها باید مراقب تکرار و Overlap نیز باشیم.

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

ترکیب Test Techniqueها معمولاً زمانی ارزش بیشتری دارد که:

• Requirement چند قانون هم‌زمان داشته باشد.
• Feature دارای Boundaryهای مهم باشد.
• چند شرط بر نتیجه تأثیر بگذارند.
• سیستم Stateهای مختلف داشته باشد.
• Risk بالایی وجود داشته باشد.
• یک تکنیک به‌تنهایی Coverage کافی ایجاد نکند.

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

Boundary Value Analysis
        +
Decision Table Testing
        +
State Transition Testing

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

یک نکته مهم درباره ترکیب تکنیک‌ها

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

ابتدا باید Test Condition و Risk را بشناسیم و سپس ببینیم کدام تکنیک یا ترکیب تکنیک‌ها با منابع موجود بهترین نتیجه را ایجاد می‌کند.

به بیان ساده:

اول Test Design، بعد انتخاب Test Technique؛ نه برعکس.

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

اما اگر ابتدا Test Conditionها و Riskها مشخص شوند، انتخاب تکنیک هدفمندتر خواهد بود.

در نتیجه، ترکیب Test Techniqueها زمانی ارزشمند است که هر تکنیک بخش متفاوتی از رفتار سیستم را پوشش دهد و در نهایت به طراحی تست‌های مؤثرتر و غیرتکراری منجر شود.

۱۶. Test Design و Test Case؛ چه تفاوتی دارند؟

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

Test Design درباره تصمیم‌گیری و طراحی تست‌هاست، در حالی که Test Case یک تست مشخص و قابل اجراست.

Test Design چیست؟

در Test Design، تستر تصمیم می‌گیرد:

• چه شرایطی باید تست شوند؟
• کدام رفتارهای سیستم اهمیت بیشتری دارند؟
• چه داده‌هایی برای تست لازم هستند؟
• چه حالت‌های مثبت و منفی باید بررسی شوند؟
• چه Boundaryهایی اهمیت دارند؟
• چه Riskهایی باید پوشش داده شوند؟
• از چه Test Techniqueهایی می‌توان استفاده کرد؟
• چه میزان Coverage مناسب است؟

بنابراین Test Design یک فعالیت تحلیلی و تصمیم‌محور است.

Test Case چیست؟

Test Case یک تست مشخص است که برای بررسی یک رفتار یا شرایط خاص سیستم طراحی شده و معمولاً اطلاعاتی مانند موارد زیر دارد:

• Test Case ID
• عنوان یا هدف تست
• Preconditions
• Test Data
• مراحل اجرا
• Expected Result
• در صورت نیاز Priority و سایر اطلاعات مرتبط

برای مثال:

عنوان: بررسی ورود کاربر با رمز عبور صحیح

Username: mehrdad
Password: ValidPass123

Expected Result: کاربر با موفقیت وارد حساب کاربری شود.

این یک Test Case مشخص و قابل اجراست.

یک مثال برای درک بهتر

فرض کنید Requirement این باشد:

«کاربر باید بتواند فایلی با حجم حداکثر ۱۰ مگابایت و فرمت PDF آپلود کند.»

در Test Design ممکن است شرایط زیر شناسایی شوند:

فرمت معتبر
فرمت نامعتبر
حجم کمتر از ۱۰ MB
حجم دقیقاً ۱۰ MB
حجم بیشتر از ۱۰ MB
فایل خالی یا خراب

سپس با توجه به این شرایط، Test Data و Test Technique مناسب انتخاب می‌شوند و در نهایت Test Caseهای مشخصی ایجاد می‌شوند.

برای مثال:

• آپلود فایل PDF با حجم دقیقاً ۱۰ مگابایت
• آپلود فایل PDF با حجم ۱۰.۱ مگابایت
• آپلود فایل JPG با حجم ۵ مگابایت

در اینجا می‌بینیم که Test Design قبل از رسیدن به Test Case به تصمیم‌گیری درباره شرایط قابل تست کمک کرده است.

تفاوت Test Design و Test Case در یک نگاه

Test Design	Test Case
فرایند طراحی تست	یک تست مشخص
تمرکز بر تصمیم‌گیری	تمرکز بر اجرای یک شرایط مشخص
Test Conditionها را شناسایی و تحلیل می‌کند	یک Test Condition را به شکل اجرایی بررسی می‌کند
Test Data موردنیاز را مشخص می‌کند	Test Data مشخص را در خود دارد
Risk و Coverage را در نظر می‌گیرد	یک تست مشخص را پوشش می‌دهد
می‌تواند از چند Test Technique استفاده کند	حاصل تصمیم‌های طراحی است
سطح مفهومی و تحلیلی بالاتری دارد	سطح اجرایی و مشخص‌تری دارد

آیا Test Design همیشه قبل از Test Case است؟

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

ممکن است هنگام طراحی یا اجرای Test Case متوجه شویم:

• یک Test Condition فراموش شده است.
• Test Data کافی نیست.
• یک Requirement ابهام دارد.
• Coverage مناسب نیست.
• یک Risk جدید شناسایی شده است.

در این حالت تستر به Test Design برمی‌گردد، آن را اصلاح می‌کند و سپس Test Caseها را نیز تغییر می‌دهد.

Test Basis
    ↓
Test Analysis
    ↓
Test Conditions
    ↓
Test Design
    ↓
Test Cases + Test Data
    ↓
Test Implementation
    ↓
Test Execution

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

Test Design بیشتر از نوشتن Test Case است

اگر تستر مستقیماً از Requirement به نوشتن Test Case برود، ممکن است فقط مسیرهای واضح و اصلی را ببیند.

اما Test Design باعث می‌شود قبل از نوشتن تست‌های اجرایی، سؤال‌های مهم‌تری مطرح شوند:

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

بنابراین Test Case یکی از خروجی‌های Test Design است، نه خود Test Design.

هدف Test Design صرفاً تولید Test Case بیشتر نیست، بلکه طراحی مجموعه‌ای هدفمند، قابل توجیه و متناسب با Risk و Coverage موردنیاز است.

۱۷. Test Design و Test Scenario؛ چه تفاوتی دارند؟

Test Design و Test Scenario نیز مانند Test Design و Test Case، مفاهیم مرتبطی هستند که گاهی با یکدیگر اشتباه گرفته می‌شوند.

تفاوت اصلی این است که Test Scenario یک وضعیت یا شرایط سطح‌بالا برای بررسی یک رفتار سیستم است، اما Test Design فرایند تصمیم‌گیری درباره این است که چه تست‌هایی و با چه شرایطی باید طراحی شوند.

Test Scenario چیست؟

Test Scenario یک سناریوی سطح‌بالا برای بررسی یک قابلیت، رفتار یا مسیر مهم سیستم است.

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

سناریو تست: بررسی فرایند خرید محصول توسط کاربر

این سناریو می‌تواند بخش‌هایی مانند انتخاب محصول، اضافه کردن به سبد خرید، ورود یا ثبت‌نام، پرداخت و ثبت سفارش را در بر بگیرد؛ اما هنوز جزئیات دقیقی مانند Test Data، مراحل اجرا یا Expected Result برای هر حالت مشخص نشده است.

Test Design چیست؟

در Test Design، تستر از اطلاعات موجود درباره سیستم استفاده می‌کند تا مشخص کند:

• چه شرایطی باید تست شوند؟
• چه Test Conditionهایی اهمیت دارند؟
• چه داده‌هایی لازم است؟
• چه حالت‌های مثبت و منفی باید بررسی شوند؟
• چه Boundaryهایی وجود دارند؟
• چه Riskهایی مهم هستند؟
• چه Test Techniqueهایی مناسب هستند؟
• چه Coverageای موردنیاز است؟

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

یک مثال ساده

فرض کنید Feature موردنظر، ورود کاربر به سیستم باشد.

ممکن است Test Scenario این باشد:

بررسی قابلیت ورود کاربر به حساب کاربری

حالا در Test Design، تستر شرایط مختلفی را شناسایی می‌کند:

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

سپس بر اساس این شرایط، Test Data و Test Technique مناسب انتخاب می‌شود و در نهایت Test Caseهای مشخص طراحی می‌شوند.

Test Scenario
      ↓
Test Design
      ↓
Test Conditions
      ↓
Test Cases + Test Data

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

تفاوت Test Scenario و Test Case

برای درک بهتر Test Design، تفاوت Test Scenario و Test Case نیز مهم است.

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

برای مثال:

Test Scenario: بررسی ورود کاربر

این سناریو می‌تواند به Test Caseهای مختلفی تبدیل شود:

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

Test Design با Test Scenario چه رابطه‌ای دارد؟

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

تستر ممکن است Test Design را بر اساس منابع مختلفی انجام دهد، مانند:

• Requirement
• User Story
• Acceptance Criteria
• Use Case
• Business Rules
• Risk Information
• Test Scenario
• مستندات فنی

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

Test Design = تبدیل Test Scenario به Test Case

این تعریف بیش از حد ساده است و بخش مهمی از Test Design، یعنی تحلیل شرایط، Risk، Coverage، Test Data و انتخاب تکنیک را نادیده می‌گیرد.

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

Test Scenario
«چه سناریوی کلی را بررسی کنیم؟»
          ↓
Test Design
«چه شرایط، داده‌ها و تست‌هایی برای بررسی آن لازم است؟»
          ↓
Test Case
«این تست مشخص را دقیقاً چگونه اجرا کنیم؟»

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

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

۱۸. مثال کامل: طراحی تست برای یک Feature

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

فرض کنید در یک فروشگاه اینترنتی، Feature زیر در حال توسعه است:

«کاربر باید بتواند با وارد کردن یک کد تخفیف معتبر، برای سفارش‌های حداقل ۵۰۰ هزار تومان تخفیف دریافت کند.»

در نگاه اول، ممکن است یک Test Case ساده برای این Requirement کافی به نظر برسد؛ اما در Test Design باید شرایط مختلفی که می‌توانند روی رفتار سیستم تأثیر بگذارند شناسایی شوند.

مرحله ۱: بررسی Requirement

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

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

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

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

این سؤالات به شناسایی Test Conditionها کمک می‌کنند؛ البته بعضی از آن‌ها ممکن است نیازمند بررسی Business Rules یا سایر اطلاعات موجود در Test Basis باشند.

مرحله ۲: شناسایی Test Conditionها

مبلغ کمتر از ۵۰۰ هزار تومان
مبلغ دقیقاً ۵۰۰ هزار تومان
مبلغ بیشتر از ۵۰۰ هزار تومان

کد تخفیف معتبر
کد تخفیف نامعتبر
کد تخفیف منقضی‌شده
کد تخفیف قبلاً استفاده‌شده

کاربر مجاز
کاربر غیرمجاز

البته همه این موارد لزوماً از Requirement اصلی استخراج نمی‌شوند و ممکن است بر اساس Business Rule، Risk یا سایر اطلاعات موجود در Test Basis شناسایی شوند.

مرحله ۳: شناسایی Boundaryها

حداقل مبلغ سفارش ۵۰۰ هزار تومان است؛ بنابراین این مقدار یک Boundary مهم محسوب می‌شود.

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

499,999
500,000
500,001

این مقادیر می‌توانند به کمک Boundary Value Analysis در طراحی تست استفاده شوند.

مرحله ۴: بررسی Positive و Negative Conditions

اکنون باید هم شرایط مثبت و هم شرایط منفی را در نظر بگیریم.

Positive:

مبلغ کافی
کد معتبر
کاربر مجاز

انتظار داریم تخفیف اعمال شود.

Negative:

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

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

مرحله ۵: انتخاب Test Technique

در این مثال می‌توان از چند تکنیک استفاده کرد.

Boundary Value Analysis برای بررسی حداقل مبلغ سفارش:

499,999
500,000
500,001

Equivalence Partitioning برای دسته‌بندی مبالغ:

کمتر از ۵۰۰,۰۰۰
۵۰۰,۰۰۰ یا بیشتر

Decision Table Testing برای بررسی ترکیب شرایط مختلف:

مبلغ کافی	کد معتبر	کاربر مجاز	نتیجه
بله	بله	بله	تخفیف اعمال شود
خیر	بله	بله	تخفیف اعمال نشود
بله	خیر	بله	تخفیف اعمال نشود
بله	بله	خیر	تخفیف اعمال نشود

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

مرحله ۶: طراحی Test Data

حالا داده‌های موردنیاز را مشخص می‌کنیم:

Order Amount:
499,999
500,000
500,001

Coupon:
VALID10
INVALID10
EXPIRED10
USED10

User:
Authorized
Unauthorized

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

مرحله ۷: بررسی Risk

حالا باید مشخص کنیم کدام شرایط Risk بیشتری دارند.

Risk بالا:

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

Risk متوسط:

• نمایش پیام خطای نامناسب
• رفتار سیستم در کد منقضی‌شده

بنابراین شرایط پرریسک باید با دقت بیشتری طراحی و اجرا شوند.

مرحله ۸: تبدیل طراحی به Test Case

اکنون می‌توان Test Caseهای مشخصی ایجاد کرد.

Test Case 1: اعمال کد تخفیف معتبر

Precondition: کاربر مجاز است و سفارش ۵۰۰ هزار تومان یا بیشتر است.

Order Amount: 500,000
Coupon: VALID10

Expected Result: کد تخفیف با موفقیت اعمال شود و مبلغ سفارش مطابق قوانین تخفیف محاسبه شود.

Test Case 2: سفارش کمتر از حداقل مبلغ

Order Amount: 499,999
Coupon: VALID10

Expected Result: کد تخفیف اعمال نشود و پیام مناسب نمایش داده شود.

Test Case 3: کد تخفیف نامعتبر

Order Amount: 500,000
Coupon: INVALID10

Expected Result: کد تخفیف پذیرفته نشود.

Test Case 4: استفاده مجدد از کد تخفیف

Order Amount: 700,000
Coupon: USED10

Expected Result: سیستم از اعمال مجدد کد تخفیف جلوگیری کند.

آنچه در این مثال اتفاق افتاد

در این مثال، مستقیماً از Requirement به Test Case نرفتیم.

Requirement
      ↓
Test Analysis
      ↓
Test Conditions
      ↓
Positive / Negative Conditions
      ↓
Boundary + Risk
      ↓
Test Technique
      ↓
Test Data
      ↓
Test Coverage
      ↓
Test Cases

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

در پروژه واقعی نیز ممکن است پس از طراحی یا اجرای Test Caseها، Test Designer متوجه یک شرط جدید یا Coverage ناکافی شود و دوباره به مراحل قبلی برگردد. به همین دلیل Test Design را بهتر است یک فعالیت Iterative در نظر بگیریم، نه یک مرحله کاملاً خطی و یک‌باره.

۱۹. Test Design در Agile

در محیط‌های Agile، Test Design معمولاً فعالیتی نیست که فقط در پایان توسعه انجام شود. طراحی تست می‌تواند از زمانی که نیازمندی یا User Story مطرح می‌شود آغاز شود و در طول توسعه و تست، به‌صورت تکرارشونده ادامه پیدا کند.

این موضوع با ماهیت Agile هماهنگ است؛ زیرا Requirementها ممکن است در طول Sprint تغییر کنند، Acceptance Criteria اصلاح شوند و اطلاعات جدیدی درباره Feature به دست آید.

Test Design در User Story

فرض کنید User Story زیر را داریم:

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

در نگاه اول، ممکن است یک Test Scenario ساده ایجاد کنیم:

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

اما در Test Design باید شرایط بیشتری بررسی شوند، برای مثال:

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

البته اینکه کدام موارد واقعاً باید تست شوند، به Acceptance Criteria، Business Rules و Risk بستگی دارد.

نقش Acceptance Criteria در Test Design

در Agile، Acceptance Criteria یکی از منابع مهم برای طراحی تست است.

فرض کنید Acceptance Criteria این باشد:

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

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

موجودی = 0
موجودی = 1
موجودی > 1
تعداد درخواست‌شده > موجودی

سپس بر اساس Risk و ماهیت Feature، Test Data و Test Technique مناسب انتخاب می‌شود.

بنابراین Acceptance Criteria می‌تواند مستقیماً به Test Condition و Test Design کمک کند.

Test Design در طول Sprint

در یک تیم Agile، طراحی تست می‌تواند در مراحل مختلف Sprint انجام شود.

User Story
    ↓
بررسی Requirement و Acceptance Criteria
    ↓
شناسایی Test Conditions
    ↓
شناسایی Risk و Boundaryها
    ↓
انتخاب Test Technique
    ↓
طراحی Test Cases / Test Data
    ↓
توسعه Feature
    ↓
اجرای تست
    ↓
بازبینی و اصلاح Test Design

این روند الزاماً خطی نیست. ممکن است هنگام توسعه مشخص شود که یک Rule تغییر کرده یا یک حالت جدید به Feature اضافه شده است. در این صورت Test Design نیز باید به‌روزرسانی شود.

Shift-Left و Test Design

در رویکرد Shift-Left Testing، فعالیت‌های تست هرچه زودتر در چرخه توسعه انجام می‌شوند. Test Design نیز می‌تواند از همین رویکرد بهره ببرد.

برای مثال، قبل از اینکه Developer کد Feature را کامل کند، Tester می‌تواند User Story و Acceptance Criteria را بررسی کند و سؤالاتی مانند این موارد مطرح کند:

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

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

همکاری Tester و Developer

در Agile، Test Design الزاماً وظیفه‌ای کاملاً جدا از سایر اعضای تیم نیست. Tester، Developer، Product Owner و سایر اعضای تیم می‌توانند درباره شرایط قابل تست و رفتار مورد انتظار سیستم با یکدیگر گفت‌وگو کنند.

برای مثال، در بررسی یک User Story ممکن است Tester بپرسد:

«اگر پرداخت با موفقیت انجام شود ولی پاسخ درگاه به سیستم ما نرسد، وضعیت سفارش چه خواهد بود؟»

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

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

Test Design و تغییرات مداوم در Agile

یکی از ویژگی‌های Agile، پذیرش تغییر است.

فرض کنید ابتدا Requirement می‌گوید:

حداقل مبلغ سفارش برای استفاده از کد تخفیف ۵۰۰ هزار تومان است.

اما در میانه Sprint این مقدار به ۷۰۰ هزار تومان تغییر می‌کند.

در چنین شرایطی، فقط Requirement تغییر نمی‌کند؛ بلکه موارد زیر نیز ممکن است نیاز به بازبینی داشته باشند:

• Test Conditions
• Boundaryها
• Test Data
• Test Cases
• Expected Results
• Coverage
• Automation Tests

بنابراین Test Design در Agile باید قابل تغییر و قابل بازبینی باشد.

Test Design در Definition of Done

در برخی تیم‌های Agile، انجام تست و برآورده شدن معیارهای کیفیت بخشی از Definition of Done است.

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

Acceptance Criteria ✓
Positive Tests ✓
Negative Tests ✓
Important Boundary Tests ✓
High-Risk Conditions ✓
Required Test Data ✓
Relevant Automation ✓

البته جزئیات Definition of Done در هر تیم متفاوت است و نباید یک فهرست ثابت را برای همه پروژه‌ها در نظر گرفت.

نکته مهم

Agile به این معنی نیست که تستر باید بدون برنامه و صرفاً به‌صورت Exploratory تست کند.

برعکس، Test Design همچنان اهمیت زیادی دارد؛ اما این طراحی باید با شرایط Agile سازگار باشد:

• زود شروع شود.
• با تیم همکاری شود.
• با تغییرات Requirement به‌روزرسانی شود.
• روی Riskهای مهم تمرکز کند.
• از مستندسازی سنگین و غیرضروری پرهیز کند.
• در صورت نیاز، تست‌های دستی و خودکار را در کنار هم در نظر بگیرد.

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

۲۰. Test Design در API و Automation

Test Design فقط برای تست رابط کاربری (UI) کاربرد ندارد. همین اصول در API Testing و Automation Testing نیز استفاده می‌شوند؛ با این تفاوت که نوع Test Condition، Test Data و Expected Result می‌تواند متفاوت باشد.

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

Test Design در API Testing

فرض کنید یک API برای ایجاد سفارش داریم:

POST /orders

و API انتظار دارد اطلاعاتی مانند موارد زیر دریافت کند:

{
  "productId": 125,
  "quantity": 2,
  "customerId": 50
}

در Test Design فقط نباید بررسی کنیم که یک Request معتبر با موفقیت پاسخ می‌گیرد. می‌توان Test Conditionهای مختلفی را شناسایی کرد:

• همه پارامترها معتبر باشند.
• یک پارامتر وجود نداشته باشد.
• مقدار یک پارامتر null باشد.
• نوع داده اشتباه باشد.
• مقدار خارج از محدوده باشد.
• productId وجود نداشته باشد.
• quantity صفر باشد.
• quantity منفی باشد.
• کاربر مجوز ایجاد سفارش نداشته باشد.
• Request تکراری ارسال شود.
• سرویس وابسته در دسترس نباشد.

در نتیجه، Test Design در API می‌تواند بسیار فراتر از بررسی یک Response موفق باشد.

Test Data در API Test Design

در API Testing، طراحی Test Data اهمیت زیادی دارد.

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

-1
0
1
2
حداکثر مقدار مجاز
بیشتر از حداکثر
null
رشته

هرکدام از این داده‌ها می‌توانند یک Test Condition خاص را فعال کنند.

همچنین در APIها ممکن است داده‌ها به یکدیگر وابسته باشند. مثلاً برای ایجاد سفارش:

Customer
    ↓
Product
    ↓
Order

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

بنابراین Test Design باید Dependency بین داده‌ها و سرویس‌ها را نیز در نظر بگیرد.

Test Design و Automation

وقتی Test Design انجام شد، می‌توان بررسی کرد کدام Test Caseها برای Automation مناسب هستند.

نوع تست	مناسب برای Automation؟
تست تکراری و پایدار	معمولاً بله
Regression Test	معمولاً بله
تست با داده‌های زیاد	معمولاً بله
تست API	اغلب بله
تست پیچیده و یک‌باره	ممکن است مناسب نباشد
تست Exploratory	معمولاً بیشتر دستی
تست نیازمند قضاوت انسانی	اغلب دشوارتر برای Automation

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

Automation از Test Design شروع می‌شود

یک اشتباه رایج این است که تصور کنیم:

«اگر تستی را با Playwright یا ابزار دیگری خودکار کنیم، پس طراحی تست نیز انجام شده است.»

در حالی که Automation فقط روش اجرای تست را تغییر می‌دهد.

چه چیزی را تست می‌کنیم؟
        ↓
Test Condition چیست؟
        ↓
چه داده‌ای لازم داریم؟
        ↓
Expected Result چیست؟
        ↓
این تست چه Risk یا Coverageای را پوشش می‌دهد؟
        ↓
آیا Automation برای آن مناسب است؟

بعد از این تصمیم‌ها می‌توان تست را با ابزار مناسب پیاده‌سازی کرد.

یک مثال ساده با Playwright

فرض کنید Test Design برای صفحه Login این شرایط را شناسایی کرده است:

Valid Login
Invalid Password
Empty Password
Locked Account

همه این شرایط ممکن است ارزش Automation داشته باشند. در نتیجه می‌توان برای هرکدام Test Case مشخصی طراحی کرد و سپس آن‌ها را با Playwright خودکارسازی کرد.

اما اگر بدون Test Design مستقیماً شروع به نوشتن کد کنیم، ممکن است ده‌ها تست برای Login موفق ایجاد کنیم و در مقابل، حالت‌هایی مانند Account Locked یا Invalid Password را فراموش کنیم.

Test Design در API و Automation چه تفاوتی ایجاد می‌کند؟

در UI معمولاً مواردی مانند عناصر صفحه، تعامل کاربر، Navigation و Validation پیام‌ها اهمیت بیشتری دارند.

در API بیشتر با مواردی مانند Request، Response، Status Code، Headers، Authentication، Schema، Data Validation و Error Handling سروکار داریم.

اما منطق اصلی Test Design در هر دو مشابه است:

ابتدا مشخص کنیم چه شرایطی باید تست شوند؛ سپس Test Data، Coverage و روش اجرای مناسب را تعیین کنیم.

Test Design و Automation یک رابطه یک‌طرفه ندارند

Automation نیز می‌تواند به بازبینی Test Design کمک کند.

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

• Test Data قابل تکرار نیست.
• یک Precondition به سیستم دیگری وابسته است.
• Expected Result به اندازه کافی مشخص نیست.
• تست بیش از حد به محیط وابسته است.
• اجرای تست دشوار یا پرهزینه است.

در این شرایط، ممکن است لازم باشد Test Design نیز بازبینی شود.

Test Design
     ↓
Test Cases
     ↓
Automation
     ↓
Execution & Feedback
     ↓
بازبینی Test Design در صورت نیاز

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

۲۱. نقش AI در Test Design 🤖

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

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

AI چگونه می‌تواند به Test Design کمک کند؟

یکی از کاربردهای مهم AI، تحلیل اطلاعاتی است که به‌عنوان Test Basis در اختیار تستر قرار می‌گیرد.

برای مثال، اگر یک User Story و Acceptance Criteria در اختیار AI قرار دهیم، می‌تواند پیشنهادهایی برای موارد زیر ارائه کند:

• Test Condition
• Positive و Negative Test
• Boundary Condition
• Edge Case
• Test Data
• Riskهای احتمالی
• Test Caseهای پیشنهادی

برای مثال، فرض کنید Requirement این باشد:

«کاربر باید بتواند فایلی با حجم حداکثر ۱۰ مگابایت و فرمت PDF آپلود کند.»

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

PDF کمتر از ۱۰ MB
PDF دقیقاً ۱۰ MB
PDF بیشتر از ۱۰ MB
فرمت غیر PDF
فایل خالی
فایل خراب
نام فایل بسیار طولانی

این پیشنهادها می‌توانند نقطه شروع مناسبی برای Test Design باشند.

AI در شناسایی Test Condition

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

برای مثال، تستر می‌تواند از AI بپرسد:

«از این Requirement چه Test Conditionهایی می‌توان استخراج کرد؟ شرایط مثبت، منفی، Boundary و Edge Case را نیز در نظر بگیر.»

AI می‌تواند فهرستی از شرایط احتمالی ایجاد کند؛ اما این فهرست نباید بدون بررسی وارد Test Suite شود.

تستر باید بررسی کند:

• آیا این Condition واقعاً از Requirement پشتیبانی می‌شود؟
• آیا برای سیستم فعلی مرتبط است؟
• آیا Risk آن به اندازه‌ای هست که ارزش تست داشته باشد؟
• آیا AI چیزی را بر اساس فرضیات خودش اضافه کرده است؟

بنابراین AI بیشتر نقش دستیار Test Designer را دارد.

AI در تولید Test Data

تولید Test Data یکی دیگر از حوزه‌هایی است که AI می‌تواند در آن مفید باشد.

برای مثال، اگر Requirement شامل محدوده سنی ۱۸ تا ۶۰ سال باشد، AI می‌تواند داده‌های نمونه‌ای مانند موارد زیر پیشنهاد دهد:

17
18
19
30
59
60
61

یا برای یک API می‌تواند نمونه‌هایی از Valid Data، Invalid Data، Missing Fields، Null Values، Boundary Values و Data Combinations پیشنهاد کند.

با این حال، داده تولیدشده باید با قوانین واقعی سیستم بررسی شود و نباید صرفاً به دلیل تولید شدن توسط AI معتبر فرض شود.

AI و Test Technique

AI همچنین می‌تواند در انتخاب یا پیشنهاد Test Technique کمک کند.

• اگر Requirement شامل یک محدوده عددی باشد، می‌تواند Boundary Value Analysis را پیشنهاد دهد.
• اگر چند شرط روی نتیجه تأثیر داشته باشند، می‌تواند Decision Table Testing را پیشنهاد دهد.
• اگر رفتار سیستم به Stateهای مختلف وابسته باشد، می‌تواند State Transition Testing را پیشنهاد دهد.

اما اینجا نیز تصمیم نهایی باید با توجه به Test Condition، Risk و Context سیستم گرفته شود. AI نباید صرفاً بر اساس چند کلمه کلیدی، یک تکنیک را به‌صورت خودکار انتخاب کند.

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

یکی از کاربردهای جالب AI در Test Design، استفاده از آن به‌عنوان یک Second Pair of Eyes است.

فرض کنید تستر Test Conditionهای زیر را طراحی کرده است:

Login با اطلاعات صحیح
Login با رمز اشتباه
Login با کاربر ناموجود

AI می‌تواند پیشنهاد دهد:

• Username خالی
• Password خالی
• هر دو خالی
• Account Locked
• Session Expired
• چند تلاش ناموفق
• دسترسی کاربر با Role متفاوت

ممکن است برخی از این موارد برای سیستم موردنظر اصلاً مرتبط نباشند؛ اما AI می‌تواند کمک کند تستر نقاط کور احتمالی را دوباره بررسی کند.

AI نباید Requirement را حدس بزند

این یکی از مهم‌ترین محدودیت‌های استفاده از AI در Test Design است.

فرض کنید Requirement فقط می‌گوید:

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

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

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

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

در چنین شرایطی، پیشنهاد AI باید به‌عنوان یک سؤال یا موضوع قابل بررسی دیده شود:

«آیا سیستم باید در این شرایط چنین رفتاری داشته باشد؟»

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

AI و Test Coverage

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

برای مثال، می‌توان Test Conditionهای طراحی‌شده را به AI داد و از آن خواست بررسی کند:

«آیا در این مجموعه تست، شرایط مهمی وجود دارند که پوشش داده نشده باشند؟»

AI می‌تواند موارد احتمالی مانند موارد زیر را پیشنهاد کند:

Boundary Coverage → ناقص
Negative Conditions → ناقص
Permission → بررسی نشده
Error Handling → بررسی نشده

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

مهم‌ترین محدودیت AI در Test Design

AI می‌تواند تست‌های زیاد تولید کند، اما زیاد بودن Test Caseها به معنی خوب بودن Test Design نیست.

• تست‌های تکراری تولید کند.
• شرایط غیرمرتبط پیشنهاد دهد.
• Requirement را اشتباه تفسیر کند.
• Business Rule را نادیده بگیرد.
• Risk واقعی سیستم را تشخیص ندهد.
• Expected Result نادرستی پیشنهاد کند.
• شرایطی را بر اساس دانش عمومی خودش فرض کند که در محصول وجود ندارند.

بنابراین تستر باید خروجی AI را Review و Validate کند.

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

Requirement / User Story
        ↓
AI برای پیشنهاد اولیه
        ↓
Test Conditions پیشنهادی
        ↓
بررسی توسط Tester
        ↓
Risk + Business Rules + Context
        ↓
Test Design نهایی
        ↓
Test Cases + Test Data
        ↓
Execution

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

در آینده، توانایی کار با AI می‌تواند یکی از مهارت‌های مهم Test Designer باشد؛ اما ارزش اصلی تستر همچنان در درک سیستم، تحلیل Requirement، شناخت Risk، پرسیدن سؤال درست و قضاوت درباره ارزش یک تست باقی می‌ماند.

بنابراین بهترین نگاه به AI در Test Design این نیست که:

«AI برای من تست طراحی کند.»

بلکه بهتر است آن را این‌گونه ببینیم:

«AI به من کمک کند نقاط کور را پیدا کنم، گزینه‌های بیشتری ببینم و فرایند طراحی تست را سریع‌تر و مؤثرتر انجام دهم.»

۲۲. اشتباهات رایج در Test Design

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

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

۱. شروع مستقیم از Test Case

یکی از رایج‌ترین اشتباهات این است که تستر بلافاصله بعد از دیدن Requirement شروع به نوشتن Test Case کند.

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

رویکرد بهتر این است که ابتدا Requirement تحلیل شود، Test Conditionهای مهم شناسایی شوند و سپس بر اساس آن‌ها Test Case طراحی شود.

Requirement
    ↓
Test Analysis
    ↓
Test Conditions
    ↓
Test Design
    ↓
Test Cases

۲. تمرکز بیش از حد روی Happy Path

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

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

Username و Password صحیح → ورود موفق

در حالی که شرایط دیگری مانند Password اشتباه، اطلاعات خالی، Account Locked یا دسترسی نامعتبر نیز ممکن است اهمیت داشته باشند.

Test Design مناسب باید در کنار شرایط مثبت، شرایط منفی و خطاهای مهم را نیز در نظر بگیرد.

۳. تلاش برای تست کردن همه چیز

اشتباه دیگر این است که تصور کنیم یک Test Design خوب باید تمام حالت‌های ممکن را پوشش دهد.

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

به همین دلیل باید از Risk، Test Technique و Coverage برای انتخاب تست‌های ارزشمند استفاده کرد.

هدف، بیشترین تعداد Test Case نیست؛ بلکه پوشش مناسب شرایط مهم با منابع موجود است.

۴. نادیده گرفتن Boundary و Edge Case

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

برای مثال، اگر مقدار مجاز بین ۱۰۰ تا ۱۰۰۰ باشد، تست کردن فقط مقدار ۵۰۰ کافی نیست.

99
100
101
999
1000
1001

این مقادیر می‌توانند رفتار سیستم در نزدیکی مرزها را بهتر مشخص کنند. البته این به معنی اجرای خودکار همه مقادیر نیست؛ بلکه Test Designer باید بر اساس Requirement و Risk تصمیم بگیرد کدام Boundaryها اهمیت دارند.

۵. انتخاب Test Technique بدون درک Test Condition

گاهی تستر تلاش می‌کند برای هر Requirement حتماً یک Test Technique انتخاب کند. این رویکرد اشتباه است.

ابتدا باید مشخص شود چه چیزی باید تست شود و سپس بر اساس ماهیت آن Test Condition، تکنیک مناسب انتخاب شود.

• محدوده عددی → ممکن است BVA مناسب باشد.
• کلاس‌های مختلف ورودی → ممکن است Equivalence Partitioning مناسب باشد.
• ترکیب چند Business Rule → ممکن است Decision Table مناسب باشد.
• Stateهای مختلف → ممکن است State Transition مناسب باشد.

اول Test Condition، بعد انتخاب Test Technique.

۶. نادیده گرفتن Risk

ممکن است دو Feature از نظر تعداد Test Condition مشابه باشند، اما اهمیت آن‌ها برای کسب‌وکار یکسان نباشد.

برای مثال، یک مشکل در تغییر تصویر پروفایل معمولاً با یک مشکل در پرداخت آنلاین پیامد یکسانی ندارد.

اگر Risk در Test Design در نظر گرفته نشود، ممکن است زمان زیادی برای تست بخش‌های کم‌اهمیت صرف شود و در مقابل، Featureهای حساس پوشش کافی نداشته باشند.

۷. طراحی Test Data بدون ارتباط با Test Condition

گاهی Test Data به‌صورت تصادفی یا صرفاً برای پر کردن Test Caseها انتخاب می‌شود.

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

برای مثال، اگر هدف بررسی محدودیت حداقل سن ۱۸ سال است، داده‌های 17، 18 و 19 ارزش بیشتری نسبت به چند مقدار تصادفی مانند 25، 32 و 41 دارند.

Test Data باید در خدمت Test Design باشد، نه اینکه صرفاً بخشی از Test Case باشد.

۸. ایجاد Test Caseهای تکراری

ممکن است چند Test Case ظاهراً متفاوت باشند اما در واقع یک رفتار مشابه را بررسی کنند.

این موضوع معمولاً زمانی اتفاق می‌افتد که Test Conditions و Coverage به‌درستی بررسی نشده باشند.

• زمان اجرای تست را افزایش می‌دهند.
• Maintenance بیشتری ایجاد می‌کنند.
• در Automation هزینه نگهداری را بالا می‌برند.
• ارزش واقعی Test Suite را کاهش می‌دهند.

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

۹. فرض کردن رفتار سیستم بدون بررسی Requirement

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

برای مثال، اگر Requirement مشخص نکرده باشد که بعد از سه بار ورود ناموفق حساب کاربر باید Lock شود، تستر نباید صرفاً بر اساس انتظار شخصی خود این رفتار را به‌عنوان Expected Result در نظر بگیرد.

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

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

۱۰. در نظر نگرفتن تغییرات سیستم

در پروژه‌های واقعی Requirementها و Featureها ممکن است تغییر کنند.

اگر یک Business Rule تغییر کند، ممکن است لازم باشد موارد زیر نیز بازبینی شوند:

• Test Conditions
• Test Data
• Test Cases
• Expected Results
• Coverage
• Automation Tests

بنابراین Test Design یک فعالیت کاملاً ثابت و یک‌باره نیست و باید در صورت تغییر اطلاعات یا کشف شرایط جدید، اصلاح شود.

۱۱. تصور اینکه Automation مشکل Test Design را حل می‌کند

نوشتن تعداد زیادی تست خودکار به معنی داشتن Test Design خوب نیست.

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

مثلاً اگر Test Design برای Login فقط Happy Path را در نظر گرفته باشد، خودکارسازی صدها بار همان تست، مشکل نبود Test Conditionهای دیگر را حل نمی‌کند.

اول تست درست را طراحی کنید، سپس اجرای آن را تا حد امکان خودکار کنید.

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

بسیاری از اشتباهات Test Design به یک مشکل مشترک برمی‌گردند: تمرکز روی تولید Test Case به جای تمرکز روی طراحی هدفمند تست.

یک Test Designer خوب باید قبل از پرسیدن سؤال «چند Test Case بنویسم؟» ابتدا بپرسد:

• چه شرایطی مهم هستند؟
• چه Riskهایی وجود دارند؟
• چه داده‌هایی لازم است؟
• چه Coverageای موردنیاز است؟
• چگونه می‌توان با کمترین تست‌های غیرضروری، بیشترین ارزش را ایجاد کرد؟

این نگاه باعث می‌شود Test Design از یک فعالیت صرفاً مستندسازی به یک فرایند تحلیلی و تصمیم‌گیری برای ایجاد تست‌های مؤثر تبدیل شود.

۲۳. Test Design Checklist

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

این Checklist قرار نیست جایگزین تحلیل و قضاوت تستر شود؛ بلکه ابزاری برای بازبینی کیفیت طراحی تست است.

قبل از طراحی تست

• ☐ آیا Requirement یا Test Basis به اندازه کافی واضح است؟
• ☐ آیا Business Ruleهای مرتبط شناسایی شده‌اند؟
• ☐ آیا User Story و Acceptance Criteria در صورت وجود بررسی شده‌اند؟
• ☐ آیا ابهام یا تناقضی در Requirement وجود دارد؟
• ☐ آیا اطلاعات مربوط به Riskهای Feature در دسترس است؟

شناسایی Test Condition

• ☐ آیا بخش‌های مختلف Requirement به شرایط قابل تست تبدیل شده‌اند؟
• ☐ آیا شرایط Positive بررسی شده‌اند؟
• ☐ آیا شرایط Negative و Error بررسی شده‌اند؟
• ☐ آیا Boundaryها و محدودیت‌ها شناسایی شده‌اند؟
• ☐ آیا Edge Caseهای مهم بررسی شده‌اند؟
• ☐ آیا Stateهای مهم سیستم در نظر گرفته شده‌اند؟
• ☐ آیا Roleها و Permissionهای مرتبط بررسی شده‌اند؟
• ☐ آیا Dependencyهای مهم سیستم شناسایی شده‌اند؟

Test Data

• ☐ آیا برای Test Conditionهای مهم داده مناسب وجود دارد؟
• ☐ آیا Boundary Dataها در نظر گرفته شده‌اند؟
• ☐ آیا داده‌های Invalid و Missing در صورت نیاز بررسی شده‌اند؟
• ☐ آیا داده‌های تست قابل تکرار و کنترل هستند؟
• ☐ آیا داده‌های حساس یا واقعی به شکل امن مدیریت می‌شوند؟

Test Technique

• ☐ آیا Test Technique مناسب برای شرایط موردنظر انتخاب شده است؟
• ☐ آیا در صورت نیاز از بیش از یک تکنیک استفاده شده است؟
• ☐ آیا انتخاب تکنیک بر اساس ماهیت Test Condition و Risk انجام شده است؟
• ☐ آیا از انتخاب مکانیکی یا غیرضروری Test Techniqueها اجتناب شده است؟

Risk و Coverage

• ☐ آیا Test Conditionهای پرریسک شناسایی شده‌اند؟
• ☐ آیا شرایط مهم از نظر کسب‌وکار پوشش داده شده‌اند؟
• ☐ آیا Coverage موردنیاز برای Requirementهای مهم ایجاد شده است؟
• ☐ آیا Test Caseهای تکراری یا کم‌ارزش حذف یا ادغام شده‌اند؟
• ☐ آیا برای بخش‌های پرریسک، عمق تست بیشتری در نظر گرفته شده است؟

Test Case و اجرا

• ☐ آیا Test Conditionها به Test Caseهای مشخص و قابل اجرا تبدیل شده‌اند؟
• ☐ آیا Expected Result برای هر Test Case قابل تشخیص و معتبر است؟
• ☐ آیا Preconditions و وابستگی‌های لازم مشخص هستند؟
• ☐ آیا مشخص شده کدام تست‌ها برای Automation مناسب هستند؟
• ☐ آیا شرایط لازم برای اجرای تست، مانند Environment و Test Data، فراهم است؟

بازبینی نهایی

• ☐ آیا Test Design با Requirement و هدف Feature مطابقت دارد؟
• ☐ آیا Test Design فقط روی Happy Path تمرکز نکرده است؟
• ☐ آیا هیچ Test Condition مهمی بدون پوشش باقی نمانده است؟
• ☐ آیا Test Design بر اساس Risk اولویت‌بندی شده است؟
• ☐ آیا در صورت تغییر Requirement، Test Design نیز بازبینی شده است؟

یک سؤال کلیدی برای بازبینی Test Design

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

«اگر این سیستم واقعاً مشکل داشته باشد، چه شرایطی ممکن است باعث شود من متوجه آن نشوم؟»

این سؤال می‌تواند به کشف Test Conditionهایی کمک کند که در نگاه اول دیده نشده‌اند.

بنابراین یک Test Design خوب الزاماً طولانی‌ترین طراحی نیست؛ بلکه طراحی‌ای است که شرایط مهم، Riskهای اصلی و Coverage موردنیاز را با تعداد مناسبی تست پوشش دهد.

۲۴. جمع‌بندی

Test Design (طراحی تست) یکی از فعالیت‌های مهم در تست نرم‌افزار است که به تستر کمک می‌کند به‌جای تولید تعداد زیادی تست، روی تست‌های هدفمند، قابل توجیه و دارای Coverage مناسب تمرکز کند.

در Test Design، تستر اطلاعات موجود در Test Basis را بررسی می‌کند، Test Conditionهای مهم را شناسایی می‌کند و سپس با درنظرگرفتن مواردی مانند Test Data، شرایط Positive و Negative، Boundaryها، Riskها، Coverage و Test Techniqueها، Test Caseهای مناسب را طراحی می‌کند.

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

Test Basis
    ↓
Test Analysis
    ↓
Test Conditions
    ↓
Test Design
    ├── Test Data
    ├── Positive / Negative
    ├── Boundary / Edge Case
    ├── Risk
    ├── Coverage
    └── Test Techniques
            ↓
      Test Cases
            ↓
   Test Implementation
            ↓
      Test Execution

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

مهم‌ترین نکته

Test Design را نباید با Test Case یا Test Technique یکی دانست:

• Test Condition: چه چیزی یا چه شرایطی باید بررسی شود؟
• Test Design: چه تست‌هایی، با چه داده‌ها و پوششی باید طراحی شوند؟
• Test Technique: با چه روشی می‌توان تست‌ها را به شکل مؤثر طراحی کرد؟
• Test Case: تست مشخص و قابل اجرایی که برای بررسی یک یا چند شرط طراحی شده است.

در نتیجه، یک تستر حرفه‌ای قبل از اینکه بپرسد:

«چه Test Caseهایی بنویسم؟»

باید ابتدا بپرسد:

«چه چیزهایی واقعاً باید تست شوند و چگونه می‌توان با منابع موجود، مهم‌ترین Riskها و شرایط را به شکل مؤثر پوشش داد؟»

در محیط‌های Agile، API Testing و Automation Testing نیز همین تفکر اهمیت دارد و AI می‌تواند به‌عنوان یک ابزار کمکی برای شناسایی شرایط، تولید داده و پیدا کردن نقاط کور مورد استفاده قرار گیرد؛ اما تصمیم نهایی همچنان به تحلیل و قضاوت تستر وابسته است.

در نهایت، هدف Test Design بیشتر کردن تعداد تست‌ها نیست؛ بلکه افزایش ارزش و اثربخشی تست‌هاست.

۲۵. منابع

• ISTQB® Glossary — مرجع رسمی اصطلاحات و تعاریف تست نرم‌افزار
• ISTQB® Certified Tester Foundation Level Syllabus v4.0.1 — برای مفاهیم Test Analysis، Test Design، Test Condition، Test Case، Test Data و Test Technique
• ISO/IEC/IEEE 29119-1:2022 — مفاهیم عمومی و چارچوب استاندارد تست نرم‌افزار
• ISO/IEC/IEEE 29119-2:2021 — فرایندهای تست نرم‌افزار
• ISO/IEC/IEEE 29119-3:2021 — مستندات تست نرم‌افزار

۲۶. سوالات متداول

Test Design چیست؟

Test Design فعالیتی برای تصمیم‌گیری درباره شرایطی است که باید تست شوند و طراحی تست‌های مناسب با درنظرگرفتن Test Data، Coverage، Risk و Test Technique است.

تفاوت Test Design و Test Case چیست؟

Test Design فرایند تصمیم‌گیری و طراحی تست است، در حالی که Test Case یک تست مشخص و قابل اجراست که معمولاً شامل شرایط اولیه، داده، مراحل اجرا و Expected Result می‌شود.

آیا Test Design همان Test Technique است؟

خیر. Test Technique روشی برای طراحی مؤثر تست‌هاست؛ مانند Equivalence Partitioning و Boundary Value Analysis. Test Design مفهوم گسترده‌تری است و می‌تواند از یک یا چند تکنیک مختلف استفاده کند.

تفاوت Test Design و Test Scenario چیست؟

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

آیا Test Design فقط برای تست دستی استفاده می‌شود؟

خیر. Test Design در Manual Testing، API Testing و Automation Testing کاربرد دارد. حتی تست‌های خودکار نیز ابتدا باید از نظر Test Condition، Test Data، هدف و Coverage طراحی شوند.

آیا می‌توان همه Test Caseها را با AI تولید کرد؟

AI می‌تواند در شناسایی Test Conditionها، تولید Test Data، پیشنهاد Edge Caseها و ایجاد Test Caseهای اولیه کمک کند، اما خروجی آن باید توسط تستر بررسی و اعتبارسنجی شود.

آیا در Test Design باید همه حالت‌های ممکن سیستم را تست کنیم؟

خیر. در سیستم‌های واقعی معمولاً تست کامل همه حالت‌ها عملی یا اقتصادی نیست. Test Design باید با استفاده از Risk، Coverage و Test Techniqueها روی شرایط مهم و باارزش تمرکز کند.

مهم‌ترین ورودی‌های Test Design چیست؟

Requirement، User Story، Acceptance Criteria، Business Rules، Use Case، مستندات سیستم، اطلاعات Risk و سابقه Defectها از مهم‌ترین اطلاعاتی هستند که می‌توانند در Test Design مورد استفاده قرار گیرند.

آیا Test Design همیشه قبل از نوشتن Test Case انجام می‌شود؟

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

چرا Test Design در تست نرم‌افزار اهمیت دارد؟

زیرا کمک می‌کند تستر به‌جای تمرکز صرف بر تعداد Test Caseها، شرایط مهم، Riskها و Coverage موردنیاز را شناسایی کند و با منابع موجود تست‌های مؤثرتری طراحی کند.