وقتی یک نرمافزار ساخته میشود، درست کار کردن هر بخش بهتنهایی لزوماً به این معنی نیست که کل سیستم نیز درست کار میکند. ممکن است قابلیت ورود به حساب کاربری، جستجوی محصول، سبد خرید و پرداخت هرکدام بهصورت جداگانه عملکرد مناسبی داشته باشند؛ اما زمانی که کاربر این مراحل را در قالب یک جریان واقعی پشت سر هم انجام میدهد، مشکلات جدیدی ظاهر شوند.
اینجاست که System Testing یا تست سیستم اهمیت پیدا میکند.
در System Testing، نرمافزار بهعنوان یک سیستم یکپارچه مورد ارزیابی قرار میگیرد تا مشخص شود آیا رفتار آن با نیازمندیهای تعریفشده مطابقت دارد یا خیر. در این سطح، تمرکز دیگر فقط روی یک Unit یا ارتباط بین چند Component نیست؛ بلکه رفتار سیستم در مقیاس کلی بررسی میشود.
برای مثال، در یک فروشگاه اینترنتی ممکن است تستر این سناریو را بررسی کند:
ورود کاربر → جستجوی محصول → افزودن به سبد خرید → ثبت سفارش → پرداخت → ایجاد سفارش → ارسال اعلان
در چنین سناریویی، حتی اگر هر قسمت بهتنهایی درست کار کند، ممکن است در تعامل میان بخشهای مختلف مشکل ایجاد شود. System Testing کمک میکند رفتار و مشکلات سیستم در چنین شرایطی شناسایی و ارزیابی شوند.
در این مقاله بررسی میکنیم System Testing چیست، چه اهدافی دارد، در کجای سطوح تست قرار میگیرد، چگونه انجام میشود و چه تفاوتی با Integration Testing، End-to-End Testing و Acceptance Testing دارد. همچنین با یک مثال واقعی، نقش تستر، محیط تست، Test Data، Automation و Regression Testing در تست سیستم را بررسی خواهیم کرد.
۲. System Testing چیست؟
System Testing یا تست سیستم یکی از سطوح اصلی تست نرمافزار است که در آن نرمافزار بهعنوان یک سیستم یکپارچه مورد ارزیابی قرار میگیرد.
هدف اصلی این است که بررسی شود آیا سیستم در شرایط تعریفشده، رفتار مورد انتظار را دارد و نیازمندیهای مشخصشده را برآورده میکند یا خیر.
به زبان ساده، در System Testing دیگر فقط نمیپرسیم:
«آیا این Component درست کار میکند؟»
یا:
«آیا این دو Component میتوانند با یکدیگر ارتباط برقرار کنند؟»
بلکه سؤال اصلی این است:
«آیا کل سیستم، وقتی اجزای آن در کنار یکدیگر قرار گرفتهاند، همان چیزی را انجام میدهد که از آن انتظار داریم؟»
یک مثال ساده
فرض کنید یک فروشگاه اینترنتی شامل بخشهای زیر است:
- سیستم ورود کاربران
- کاتالوگ محصولات
- سبد خرید
- سیستم سفارش
- درگاه پرداخت
- سیستم ارسال اعلان
در مراحل قبلی ممکن است هرکدام از این اجزا بهصورت جداگانه یا در تعامل با اجزای دیگر تست شده باشند.
اما در System Testing میتوان یک جریان کامل را بررسی کرد:
Login → Search Product → Add to Cart → Checkout → Payment → Order Creation → Notification
در اینجا تستر بررسی میکند که کل سیستم در کنار هم چگونه رفتار میکند و آیا این جریان مطابق Requirements اجرا میشود یا خیر.
System Testing فقط تست قابلیتهای نرمافزار نیست
یکی از نکات مهم این است که System Testing را نباید صرفاً به Functional Testing محدود کرد.
بسته به نیازمندیها و Scope پروژه، در سطح سیستم میتوان جنبههای مختلفی را بررسی کرد؛ برای مثال:
- Functional Requirements
- Performance Requirements
- Security Requirements
- Compatibility Requirements
- Usability Requirements
- Reliability Requirements
بنابراین System Testing بیشتر به سطحی از تست اشاره دارد، نه یک Test Type واحد.
System Testing معمولاً توسط چه کسی انجام میشود؟
System Testing معمولاً در حوزه مسئولیت Testers / QA Engineers قرار میگیرد، اگرچه در پروژههای مختلف ممکن است Developers، Automation Engineers، Security Testers یا سایر اعضای تیم نیز در بخشهایی از آن مشارکت داشته باشند.
نکته مهم این است که System Testing زمانی قابل انجام است که یک نسخه قابل تست از سیستم و اجزای موردنیاز آن در اختیار تیم باشد. با این حال، در رویکردهایی مانند Agile، این تست لزوماً به یک مرحله مستقل و انتهایی محدود نمیشود و میتواند بهصورت تکرارشونده انجام شود.
در نتیجه، میتوان System Testing را اینگونه خلاصه کرد:
System Testing یعنی ارزیابی یک سیستم یکپارچه برای اطمینان از اینکه رفتار آن با نیازمندیهای تعریفشده مطابقت دارد.
۳. هدف از System Testing چیست؟
هدف System Testing فقط پیدا کردن Bug نیست. هدف اصلی این است که مطمئن شویم سیستم بهعنوان یک محصول یکپارچه، نیازمندیهای تعریفشده را برآورده میکند و در شرایط مورد انتظار رفتار صحیحی دارد.
ممکن است یک Unit یا Integration بهدرستی کار کند، اما زمانی که اجزای مختلف سیستم در کنار یکدیگر قرار میگیرند، مشکلاتی در سطح بالاتر آشکار شوند. System Testing کمک میکند این نوع مشکلات در شرایطی نزدیکتر به استفاده واقعی سیستم شناسایی شوند.
مهمترین اهداف System Testing
۱. بررسی انطباق سیستم با Requirements
یکی از مهمترین اهداف System Testing بررسی این است که سیستم مطابق Functional Requirements و Non-Functional Requirements عمل میکند.
برای مثال، اگر Requirement مشخص کرده باشد که کاربر پس از پرداخت موفق باید سفارش خود را دریافت و در حساب کاربری مشاهده کند، تستر باید این رفتار را در سطح سیستم بررسی کند.
۲. بررسی رفتار سیستم بهعنوان یک واحد کامل
در System Testing تمرکز روی رفتار سیستم در حالت یکپارچه است.
برای مثال، در یک فروشگاه اینترنتی فقط بررسی نمیکنیم که Payment Gateway بتواند یک پرداخت را انجام دهد؛ بلکه میتوانیم کل جریان زیر را بررسی کنیم:
ثبت سفارش → پرداخت → تأیید پرداخت → ایجاد سفارش → تغییر وضعیت سفارش → ارسال Notification
در اینجا سؤال این است که آیا کل این فرآیند، از ابتدا تا انتها، مطابق Requirements اجرا میشود یا خیر.
۳. شناسایی مشکلاتی که در سطوح پایینتر تست دیده نشدهاند
ممکن است Unit Testing و Integration Testing موفق باشند، اما سیستم در یک جریان کامل یا شرایط واقعیتر همچنان مشکل داشته باشد.
برای مثال:
- اطلاعات بین چند ماژول بهدرستی منتقل نمیشود.
- یک Business Rule در جریان کامل سفارش رعایت نمیشود.
- وضعیت سیستم بعد از یک عملیات بهدرستی تغییر نمیکند.
- یک سرویس خارجی پاسخ متفاوتی ایجاد میکند.
- یک Error در یک بخش باعث رفتار نادرست در بخش دیگری میشود.
System Testing فرصت میدهد چنین مشکلاتی در سطح سیستم شناسایی شوند.
۴. بررسی جریانهای واقعی کاربر
یکی از اهداف مهم System Testing بررسی Business Workflowهای واقعی است.
بهعنوان مثال:
ثبتنام → ورود به حساب → انتخاب محصول → ثبت سفارش → پرداخت → مشاهده سفارش
این نوع سناریوها نشان میدهند که سیستم در یک جریان واقعی استفاده چگونه رفتار میکند.
۵. بررسی سناریوهای مثبت و منفی
System Testing فقط برای بررسی مسیرهای موفق نیست. تستر باید بررسی کند که وقتی شرایط غیرعادی یا خطا رخ میدهد، سیستم چه رفتاری دارد.
مثلاً:
- رمز عبور اشتباه باشد.
- موجودی محصول تمام شده باشد.
- پرداخت ناموفق باشد.
- ارتباط با یک سرویس خارجی قطع شود.
- کاربر اطلاعات ناقص وارد کند.
- درخواست تکراری ارسال شود.
سیستم باید در چنین شرایطی نیز رفتاری قابل پیشبینی و مطابق Requirements داشته باشد.
۶. بررسی Non-Functional Requirements
در صورت وجود Requirements مربوط به ویژگیهای غیرعملکردی، System Testing میتواند برای بررسی آنها نیز مورد استفاده قرار گیرد.
برای مثال:
- آیا سیستم در بار مورد انتظار پاسخ مناسبی دارد؟
- آیا روی Browserهای مورد پشتیبانی درست کار میکند؟
- آیا سیستم در برابر خطاها رفتار مناسبی دارد؟
- آیا الزامات امنیتی تعریفشده رعایت شدهاند؟
البته هرکدام از این موضوعات میتوانند Test Type یا فعالیت تخصصی جداگانهای داشته باشند.
خلاصه هدف System Testing
بهطور خلاصه، System Testing میخواهد به این سؤال پاسخ دهد:
آیا سیستم یکپارچه، در شرایط مورد انتظار، همان چیزی را انجام میدهد که Requirements از آن انتظار دارند؟
بنابراین تمرکز System Testing از «درست کار کردن یک جزء» به «درست کار کردن سیستم بهعنوان یک واحد یکپارچه» منتقل میشود.
۴. System Testing در کجای سطوح تست قرار دارد؟
برای درک بهتر System Testing، ابتدا باید جایگاه آن را در Test Levels یا سطوح تست نرمافزار بشناسیم.
در یک مدل رایج، تست نرمافزار در چهار سطح اصلی انجام میشود:
Unit Testing → Integration Testing → System Testing → Acceptance Testing
هر سطح، سیستم را از زاویهای متفاوت و با هدف مشخصی بررسی میکند.
۱. Unit Testing
در Unit Testing کوچکترین واحدهای قابل تست نرمافزار، مانند یک Function، Method یا Class، بررسی میشوند.
سؤال اصلی:
آیا این Unit در شرایط موردنظر درست کار میکند؟
مثلاً بررسی اینکه تابع محاسبه تخفیف، با دریافت قیمت و درصد تخفیف، مقدار صحیح را برمیگرداند.
۲. Integration Testing
در Integration Testing تمرکز روی تعامل و ارتباط بین اجزای مختلف است.
سؤال اصلی:
آیا اجزای مختلف سیستم بهدرستی با یکدیگر ارتباط برقرار میکنند؟
برای مثال، بررسی ارتباط بین:
Order Service ↔ Payment Service
یا:
Application ↔ Database
۳. System Testing
در System Testing سیستم یکپارچه بهعنوان یک واحد کامل مورد بررسی قرار میگیرد.
سؤال اصلی:
آیا کل سیستم مطابق Requirements عمل میکند؟
برای مثال، در یک فروشگاه اینترنتی میتوان جریان زیر را بررسی کرد:
Login → Search → Cart → Checkout → Payment → Order → Notification
در این سطح دیگر تمرکز اصلی روی یک Function یا فقط ارتباط دو Component نیست؛ بلکه رفتار سیستم بهعنوان یک مجموعه یکپارچه ارزیابی میشود.
۴. Acceptance Testing
در Acceptance Testing تمرکز روی این است که آیا سیستم برای پذیرش و استفاده موردنظر مناسب است و نیازهای کسبوکار، Customer یا User را برآورده میکند یا خیر.
سؤال اصلی:
آیا این محصول نیازهای کسبوکار و انتظارات موردنظر را برآورده میکند و برای پذیرش مناسب است؟
Acceptance Testing میتواند شامل رویکردهایی مانند User Acceptance Testing (UAT) باشد.
مقایسه چهار سطح تست
| سطح تست | تمرکز اصلی | سؤال کلیدی |
|---|---|---|
| Unit Testing | یک Unit | آیا این Unit در شرایط موردنظر درست کار میکند؟ |
| Integration Testing | تعامل اجزا | آیا اجزا درست با هم کار میکنند؟ |
| System Testing | کل سیستم | آیا سیستم مطابق Requirements عمل میکند؟ |
| Acceptance Testing | نیاز کسبوکار و پذیرش | آیا محصول برای پذیرش و استفاده موردنظر مناسب است؟ |
نکته مهم درباره Test Levels
این سطوح به این معنا نیستند که همیشه باید پروژه دقیقاً به شکل خطی از Unit به Integration و سپس System و Acceptance حرکت کند.
در روشهای مدرن توسعه نرمافزار، بهخصوص Agile و Continuous Testing، این فعالیتها میتوانند در طول چرخه توسعه بارها تکرار شوند.
همچنین یک Test Level لزوماً جایگزین سطح دیگر نیست. موفق بودن Unit Testing به این معنی نیست که دیگر نیازی به System Testing نداریم؛ زیرا هر سطح میتواند نوع متفاوتی از مشکلات را آشکار کند.
System Testing در این میان نقطهای مهم است که نرمافزار را نه بهعنوان مجموعهای از اجزای جداگانه، بلکه بهعنوان یک سیستم یکپارچه و قابل استفاده ارزیابی میکند.
۵. System Testing چگونه انجام میشود؟
System Testing یک فعالیت تکمرحلهای نیست؛ بلکه مجموعهای از فعالیتهاست که از بررسی نیازمندیها و برنامهریزی تست شروع میشود و تا اجرای تست، ثبت Defect، Retesting، Regression Testing و گزارش نتایج ادامه پیدا میکند.
فرآیند دقیق ممکن است در پروژههای مختلف متفاوت باشد، اما یک جریان رایج را میتوان به شکل زیر در نظر گرفت:
Requirements → Test Planning → Test Design → Test Environment → Test Execution → Defect Reporting → Retesting → Regression Testing → Test Reporting
۱. بررسی Requirements
قبل از طراحی تست، تستر باید Requirements را بررسی کند تا مشخص شود سیستم دقیقاً چه رفتار و قابلیتهایی باید داشته باشد.
در این مرحله مواردی مانند موارد زیر بررسی میشوند:
- Functional Requirements
- Non-Functional Requirements
- Business Rules
- Acceptance Criteria
- محدودیتها و شرایط خاص سیستم
این مرحله کمک میکند Test Scenarioها بر اساس نیازمندیهای واقعی طراحی شوند، نه بر اساس حدس یا برداشت شخصی تستر.
۲. تعیین Test Scope
در پروژههای بزرگ معمولاً نمیتوان تمام سیستم را با یک سطح از جزئیات تست کرد. بنابراین باید مشخص شود چه بخشهایی در محدوده تست قرار میگیرند و چه مواردی خارج از Scope هستند.
برای مثال:
- چه قابلیتهایی باید تست شوند؟
- چه بخشهایی خارج از Scope هستند؟
- چه Environmentهایی مورد استفاده قرار میگیرند؟
- چه Browserها یا Deviceهایی باید بررسی شوند؟
- چه Test Typeهایی در این مرحله موردنیاز هستند؟
۳. آمادهسازی Test Environment
سیستم باید در یک Test Environment مناسب در دسترس تستر قرار گیرد.
این محیط ممکن است شامل موارد زیر باشد:
- Application
- Database
- APIها
- سرویسهای خارجی
- Test Accountها
- Test Data
- Configurationهای موردنیاز
هرچه Test Environment از نظر شرایط مهم، Configuration و وابستگیها به محیط واقعی نزدیکتر باشد، نتایج System Testing معمولاً قابلاعتمادتر خواهد بود.
۴. طراحی Test Scenario و Test Case
بر اساس Requirements، تستر سناریوهای مختلف را طراحی میکند.
برای مثال در یک فروشگاه اینترنتی:
Scenario: ثبت موفق سفارش
سپس میتوان Test Caseهایی برای شرایط مختلف طراحی کرد:
- پرداخت موفق
- پرداخت ناموفق
- محصول ناموجود
- موجودی ناکافی
- اطلاعات آدرس ناقص
- قطع ارتباط با Payment Gateway
در این مرحله نباید فقط Happy Path در نظر گرفته شود؛ سناریوهای منفی و شرایط غیرعادی نیز اهمیت زیادی دارند.
۵. اجرای System Test
پس از آماده شدن Environment و Test Caseها، تستها اجرا میشوند.
در حین اجرا، تستر:
- Actual Result را بررسی میکند.
- آن را با Expected Result مقایسه میکند.
- Pass یا Fail بودن Test Case را مشخص میکند.
- شواهد موردنیاز مانند Screenshot، Log یا Response را ثبت میکند.
۶. ثبت Defect
اگر نتیجه واقعی با نتیجه مورد انتظار مطابقت نداشته باشد، یک Bug Report / Defect Report ایجاد میشود.
یک گزارش مناسب معمولاً شامل مواردی مانند موارد زیر است:
- Title
- Environment
- Preconditions
- Steps to Reproduce
- Expected Result
- Actual Result
- Severity
- Priority
- Evidence
۷. Retesting
بعد از اینکه Developer مشکل را برطرف کرد، تستر همان سناریوی مشکلدار را دوباره اجرا میکند تا مشخص شود آیا Defect واقعاً برطرف شده است یا خیر.
این مرحله Retesting نام دارد.
۸. Regression Testing
رفع یک Bug ممکن است روی قسمتهای دیگر سیستم تأثیر بگذارد. بنابراین علاوه بر Retesting، لازم است بخشهای مرتبط یا مهم سیستم نیز دوباره بررسی شوند تا مشخص شود تغییر جدید باعث ایجاد مشکلات دیگری نشده است.
اینجاست که Regression Testing اهمیت پیدا میکند.
۹. Test Reporting
در پایان، نتایج System Testing مستند میشوند.
برای مثال:
- تعداد Test Caseهای اجراشده
- تعداد Pass و Fail
- Defectهای شناساییشده
- Defectهای Open و Closed
- وضعیت Regression Testing
- ریسکهای باقیمانده
- محدودیتهای تست
این اطلاعات به تیم و Stakeholderها کمک میکند وضعیت فعلی سیستم و ریسکهای باقیمانده را بهتر ارزیابی کنند.
خلاصه فرآیند
بنابراین میتوان فرآیند System Testing را بهصورت خلاصه اینگونه دید:
- Requirements را بررسی کن
- Scope را مشخص کن
- Test Environment را آماده کن
- Scenario و Test Case طراحی کن
- تستها را اجرا کن
- Defectها را ثبت کن
- Fixها را Retest کن
- Regression Testing انجام بده
- نتایج را گزارش کن
نکته مهم این است که این فرآیند الزاماً کاملاً خطی نیست. در پروژههای Agile، بسیاری از این فعالیتها در هر Sprint و برای هر Increment محصول تکرار میشوند.
۶. چه چیزهایی در System Testing تست میشوند؟
در System Testing، سیستم بهعنوان یک محصول یکپارچه بررسی میشود؛ بنابراین دامنه تست میتواند گسترده باشد. تستر باید بر اساس Requirements و Test Scope مشخص کند کدام قابلیتها و ویژگیهای سیستم باید ارزیابی شوند.
بهطور کلی، موارد مورد بررسی را میتوان در دو گروه اصلی قرار داد:
Functional Testing
در این بخش بررسی میشود که سیستم چه کاری انجام میدهد و آیا رفتار آن با Functional Requirements مطابقت دارد یا خیر.
برای مثال، در یک فروشگاه اینترنتی میتوان موارد زیر را بررسی کرد:
- ثبتنام و ورود کاربر
- جستجوی محصول
- فیلتر و مرتبسازی محصولات
- افزودن و حذف محصول از سبد خرید
- محاسبه قیمت و تخفیف
- ثبت سفارش
- پرداخت
- لغو سفارش
- تغییر وضعیت سفارش
- ارسال Email یا SMS
- مدیریت حساب کاربری
اما تستر فقط مسیرهای موفق را بررسی نمیکند. سناریوهای منفی نیز اهمیت دارند؛ مثلاً:
- ورود با رمز عبور اشتباه
- پرداخت ناموفق
- موجود نبودن محصول
- وارد کردن اطلاعات ناقص
- استفاده از کد تخفیف نامعتبر
- قطع ارتباط با یک سرویس خارجی
Non-Functional Testing
در این بخش بررسی میشود که سیستم چگونه کار میکند و آیا ویژگیهای کیفی و Non-Functional Requirements مورد انتظار را برآورده میکند یا خیر.
بر اساس Requirements و Scope پروژه، System Testing میتواند جنبههایی مانند موارد زیر را پوشش دهد:
- Performance Testing — بررسی کارایی و رفتار سیستم تحت بار
- Security Testing — بررسی الزامات و کنترلهای امنیتی
- Usability Testing — بررسی سهولت استفاده از سیستم
- Compatibility Testing — بررسی عملکرد روی Browserها، Deviceها یا محیطهای مختلف
- Reliability Testing — بررسی قابلیت اطمینان سیستم
- Recovery Testing — بررسی رفتار سیستم پس از خطا یا Failure
البته هرکدام از این موارد میتوانند فرآیند، ابزار و تخصص جداگانهای داشته باشند و لزوماً همه آنها در هر System Test اجرا نمیشوند.
فقط قابلیتها را تست نمیکنیم
یک اشتباه رایج این است که System Testing را صرفاً به بررسی Featureها محدود کنیم.
برای مثال ممکن است یک سیستم از نظر Functional کاملاً درست باشد، اما:
- در بار بالا بسیار کند شود.
- روی یک Browser پشتیبانیشده درست کار نکند.
- پس از قطع شدن یک سرویس خارجی رفتار مناسبی نداشته باشد.
- اطلاعات را به شکل ناامن مدیریت کند.
بنابراین Scope واقعی System Testing باید از Requirements و ریسکهای سیستم تعیین شود.
یک نکته مهم
همه چیزهایی که در سیستم وجود دارند الزاماً با یک روش و در یک سطح تست نمیشوند.
برای مثال، ممکن است:
- Unit Testing برای منطق داخلی یک Component
- Integration Testing برای ارتباط بین سرویسها
- System Testing برای رفتار کل سیستم
در نتیجه، System Testing قرار نیست جایگزین سایر سطوح و انواع تست شود؛ بلکه یکی از لایههای مهم در استراتژی کلی تست نرمافزار است.
۷. مثال واقعی System Testing
برای درک بهتر System Testing، یک فروشگاه اینترنتی را در نظر بگیریم.
فرض کنید این سیستم از چند بخش مختلف تشکیل شده است:
- User Authentication
- Product Catalog
- Shopping Cart
- Order Management
- Payment Gateway
- Notification Service
هرکدام از این بخشها ممکن است قبلاً بهصورت جداگانه یا در سطح Integration تست شده باشند. اما هنوز یک سؤال مهم باقی میماند:
آیا کل سیستم، وقتی کاربر از آن استفاده میکند، مطابق Requirements درست کار میکند؟
سناریوی ثبت یک سفارش
فرض کنیم یک کاربر قصد خرید یک محصول را دارد.
تستر میتواند جریان زیر را بررسی کند:
Login → Search Product → View Product → Add to Cart → Checkout → Payment → Order Creation → Notification
در هر مرحله، فقط همان صفحه یا Component بررسی نمیشود؛ بلکه نتیجه هر مرحله و تأثیر آن بر مراحل بعدی نیز مورد توجه قرار میگیرد.
- کاربر با حساب معتبر وارد سیستم میشود.
- محصول موردنظر را جستجو میکند.
- محصول را به سبد خرید اضافه میکند.
- قیمت و تعداد محصول در Cart بهدرستی نمایش داده میشود.
- کاربر وارد Checkout میشود.
- اطلاعات سفارش صحیح نمایش داده میشود.
- پرداخت با موفقیت انجام میشود.
- سیستم سفارش را ایجاد میکند.
- وضعیت سفارش به مقدار صحیح تغییر میکند.
- Notification مناسب برای کاربر ارسال میشود.
اگر هر مرحله بهتنهایی درست باشد اما مثلاً بعد از پرداخت موفق، سفارش ایجاد نشود، سیستم در این سناریو موفق به برآورده کردن Requirement نشده است.
فقط Happy Path را تست نکنیم
همین مثال را میتوان برای سناریوهای منفی نیز بررسی کرد.
مثال: پرداخت ناموفق
Login → Select Product → Add to Cart → Checkout → Payment Failed → Order نباید ایجاد شود → نمایش پیام مناسب
مثال: محصول در زمان Checkout ناموجود میشود
Add Product to Cart → Product Stock = 0 → Checkout → جلوگیری از ثبت سفارش → نمایش پیام مناسب
این سناریوها نشان میدهند که System Testing فقط بررسی مسیرهای موفق نیست؛ بلکه رفتار سیستم در شرایط مختلف و مطابق Requirements نیز اهمیت دارد.
در این مثال دقیقاً چه چیزی System Testing است؟
نکته مهم اینجاست که هدف ما صرفاً تست تکتک اجزای فروشگاه نیست.
هدف این است که بررسی کنیم:
آیا مجموعه این اجزا در کنار یکدیگر، فرآیند واقعی خرید را مطابق نیازمندیهای سیستم اجرا میکنند؟
این نوع تست میتواند مشکلاتی را آشکار کند که در تست Componentها یا Integrationهای محدود ممکن است شناسایی نشده باشند.
برای مثال:
- Payment موفق است اما Order ساخته نمیشود.
- Order ساخته میشود اما وضعیت آن اشتباه است.
- موجودی بعد از خرید بهدرستی کاهش پیدا نمیکند.
- Notification با اطلاعات اشتباه ارسال میشود.
- مبلغ پرداختشده با مبلغ Order متفاوت است.
این دقیقاً یکی از ارزشهای اصلی System Testing است: بررسی رفتار سیستم بهعنوان یک مجموعه یکپارچه در سناریوهای تعریفشده.
۸. System Testing و End-to-End Testing
System Testing و End-to-End Testing (E2E Testing) شباهت زیادی دارند و در بعضی پروژهها ممکن است در گفتگوهای روزمره به جای یکدیگر استفاده شوند؛ اما از نظر مفهومی دقیقاً یکسان نیستند.
System Testing چیست؟
System Testing یک Test Level است که در آن سیستم یکپارچه بهعنوان یک مجموعه کامل در برابر Requirements ارزیابی میشود.
تمرکز اصلی:
آیا سیستم در سطح کلی مطابق نیازمندیهای تعریفشده عمل میکند؟
این تست میتواند بر اساس Scope پروژه، جنبههای مختلف Functional و Non-Functional سیستم را پوشش دهد.
End-to-End Testing چیست؟
End-to-End Testing رویکردی برای بررسی یک جریان کامل است که از نقطه شروع تا پایان یک فرآیند را دنبال میکند.
تمرکز اصلی:
آیا یک Business Flow کامل، از ابتدا تا انتها، درست اجرا میشود؟
مثلاً در فروشگاه اینترنتی:
Login → Search → Add to Cart → Checkout → Payment → Order → Notification
در E2E Testing تلاش میشود این جریان به شکلی نزدیک به استفاده واقعی و با درنظرگرفتن وابستگیهای لازم بررسی شود.
تفاوت اصلی
| System Testing | End-to-End Testing |
|---|---|
| یک Test Level است. | رویکردی برای بررسی یک جریان کامل است. |
| تمرکز بر ارزیابی سیستم یکپارچه دارد. | تمرکز بر یک Workflow یا Business Flow کامل دارد. |
| میتواند Scope گستردهای داشته باشد. | معمولاً یک جریان مشخص را از ابتدا تا انتها دنبال میکند. |
| میتواند Functional و Non-Functional باشد. | اغلب برای بررسی جریانهای کامل Functional استفاده میشود. |
| الزاماً محدود به یک سناریوی End-to-End نیست. | ماهیت آن بر پوشش یک جریان کامل استوار است. |
آیا System Testing و E2E Testing میتوانند همزمان باشند؟
بله.
یک تست میتواند در سطح System Testing انجام شود و در عین حال یک End-to-End Scenario باشد.
برای مثال، تست فرآیند کامل خرید یک محصول از ورود کاربر تا ثبت سفارش میتواند یک System Test باشد که با رویکرد End-to-End طراحی شده است.
بنابراین بهتر است این دو مفهوم را در دو محور متفاوت ببینیم:
System Testing → در چه سطحی تست میکنیم؟
End-to-End Testing → چه جریان کاملی را بررسی میکنیم؟
یک نکته مهم درباره Automation
در Automation Testing، اصطلاح E2E Test بسیار رایج است؛ بهخصوص در ابزارهایی مانند Playwright.
مثلاً یک تست Playwright میتواند کل فرآیند خرید را از Login تا ثبت سفارش اجرا کند. چنین تستی از نظر سناریو، یک End-to-End Automated Test است.
اما صرفاً استفاده از Playwright باعث نمیشود هر تستی که نوشته میشود یک System Test باشد. سطح تست، Scope و هدف سناریو تعیین میکنند که تست دقیقاً چه چیزی را ارزیابی میکند.
در نتیجه:
System Testing و End-to-End Testing همپوشانی دارند، اما مترادف نیستند.
۹. System Testing در مقابل Integration Testing
یکی از رایجترین ابهامها در Test Levels، تفاوت بین Integration Testing و System Testing است. هر دو با اجزای یکپارچه سیستم سروکار دارند، اما هدف و Scope آنها متفاوت است.
Integration Testing چیست؟
در Integration Testing تمرکز اصلی روی تعامل و ارتباط بین دو یا چند Component، Module یا Service است.
سؤال اصلی این است:
آیا اجزای مختلف سیستم بهدرستی با یکدیگر ارتباط برقرار میکنند؟
برای مثال، در یک فروشگاه اینترنتی میتوان ارتباط بین این بخشها را بررسی کرد:
Order Service ↔ Payment Service
یا:
Application ↔ Database
در این سطح، تمرکز بیشتر روی Interface، Data Flow، Communication و Integration Point است.
System Testing چیست؟
در System Testing سیستم یکپارچه در سطح گستردهتری بررسی میشود.
سؤال اصلی این است:
آیا کل سیستم مطابق Requirements عمل میکند؟
برای مثال، بهجای اینکه فقط ارتباط Order Service و Payment Service را بررسی کنیم، میتوان یک جریان کامل را بررسی کرد:
Login → Select Product → Cart → Checkout → Payment → Order → Notification
در اینجا هدف بررسی رفتار سیستم در سطح کلی و در چارچوب Requirements است. یک Business Workflow کامل میتواند یکی از سناریوهای مناسب برای این ارزیابی باشد.
یک مثال ساده برای درک تفاوت
فرض کنید کاربر در یک فروشگاه اینترنتی سفارش خود را ثبت میکند.
در Integration Testing ممکن است فقط بررسی کنیم:
وقتی Payment Service پرداخت موفق را اعلام میکند، آیا Order Service پیام را بهدرستی دریافت میکند؟
اما در System Testing میپرسیم:
آیا کاربر میتواند از Login تا پرداخت و ایجاد سفارش، کل فرآیند خرید را مطابق Requirements با موفقیت انجام دهد؟
بنابراین ممکن است Integration Test موفق باشد، اما System Test شکست بخورد.
مثلاً:
Payment Service → Order Service
بهدرستی ارتباط برقرار میکنند، اما سیستم بعد از ایجاد Order، Notification اشتباه برای کاربر ارسال میکند.
در این حالت Integration بین دو سرویس ممکن است Pass باشد، اما Business Workflow در سطح سیستم Fail شده است.
مقایسه Integration Testing و System Testing
| ویژگی | Integration Testing | System Testing |
|---|---|---|
| سطح | بین اجزا، ماژولها یا سرویسها | کل سیستم یکپارچه |
| تمرکز | ارتباط و تعامل اجزا | رفتار سیستم مطابق Requirements |
| Scope | معمولاً محدودتر | معمولاً گستردهتر |
| سؤال اصلی | آیا اجزا درست با هم کار میکنند؟ | آیا کل سیستم مطابق نیازمندیها کار میکند؟ |
| مثال | Order ↔ Payment | Login تا ثبت سفارش |
| Business Workflow | ممکن است بخشی از آن باشد | میتواند یکی از سناریوهای مهم باشد |
آیا Integration Testing و System Testing جایگزین یکدیگرند؟
خیر.
این دو سطح مکمل یکدیگر هستند.
Integration Testing میتواند مشکلات مربوط به ارتباط و تعامل اجزای سیستم را پیدا کند، در حالی که System Testing بررسی میکند آیا سیستم یکپارچه در مجموع نیازمندیهای مورد انتظار را برآورده میکند یا خیر.
به همین دلیل، موفقیت Integration Testing بهتنهایی تضمین نمیکند که System Testing نیز موفق خواهد بود.
Integration Testing میپرسد: «آیا اجزا با هم درست کار میکنند؟»
System Testing میپرسد: «آیا کل سیستم همان کاری را انجام میدهد که باید انجام دهد؟»
۱۰. System Testing در مقابل Acceptance Testing
System Testing و Acceptance Testing هر دو میتوانند سیستم را در سطحی نسبتاً کامل بررسی کنند، اما هدف آنها یکسان نیست. تفاوت اصلی را باید در هدف تست و نوع سؤالی که میخواهیم به آن پاسخ دهیم جستوجو کرد.
Acceptance Testing چیست؟
در Acceptance Testing بررسی میشود که آیا محصول یا سیستم نیازهای کسبوکار، مشتری یا کاربران موردنظر را برآورده میکند و برای پذیرش مناسب است یا خیر.
سؤال اصلی:
آیا این محصول همان چیزی است که Customer یا Business به آن نیاز دارد؟
یکی از شناختهشدهترین شکلهای آن User Acceptance Testing (UAT) است.
System Testing چیست؟
در System Testing، سیستم یکپارچه در برابر Requirements و رفتار مورد انتظار آن ارزیابی میشود.
سؤال اصلی:
آیا سیستم مطابق نیازمندیهای مشخصشده عمل میکند؟
برای مثال، تستر میتواند بررسی کند که فرآیند ثبت سفارش، محاسبه مبلغ، پرداخت و ایجاد سفارش مطابق Specification و Requirements کار میکند.
تفاوت با یک مثال
فرض کنیم یک شرکت برای فروشگاه اینترنتی خود Requirement زیر را تعریف کرده است:
«کاربر باید بتواند محصول را انتخاب کرده، سفارش خود را ثبت و هزینه آن را پرداخت کند.»
در System Testing ممکن است تیم تست بررسی کند که:
- محصول به Cart اضافه میشود.
- مبلغ صحیح محاسبه میشود.
- Checkout درست انجام میشود.
- Payment موفق ثبت میشود.
- Order ایجاد میشود.
- وضعیت سفارش صحیح است.
اما در Acceptance Testing ممکن است Customer یا نماینده Business بررسی کند که آیا این فرآیند واقعاً نیاز کسبوکار را برآورده میکند و محصول برای استفاده یا Release قابل قبول است یا خیر.
مقایسه System Testing و Acceptance Testing
| ویژگی | System Testing | Acceptance Testing |
|---|---|---|
| هدف | ارزیابی سیستم در برابر Requirements | بررسی مناسب بودن محصول برای پذیرش |
| تمرکز | رفتار سیستم | نیاز Business، Customer یا User |
| سؤال اصلی | آیا سیستم مطابق Specification و Requirements کار میکند؟ | آیا محصول نیازهای مورد انتظار را برآورده میکند؟ |
| انجامدهندگان | معمولاً QA / Test Team | Customer، Business، End User یا نمایندگان آنها |
| هدف نهایی | ارزیابی سیستم در برابر معیارهای تعریفشده | تصمیمگیری درباره پذیرش محصول |
| مثال | بررسی کامل فرآیند ثبت سفارش | تأیید اینکه فرآیند خرید برای کسبوکار قابل قبول است |
آیا System Testing و Acceptance Testing میتوانند همپوشانی داشته باشند؟
بله.
ممکن است هر دو یک Business Flow مشابه، مثلاً ثبت سفارش، را بررسی کنند. چیزی که آنها را از هم متمایز میکند، هدف، معیار ارزیابی و تصمیمی است که قرار است بر اساس نتیجه تست گرفته شود.
در System Testing میپرسیم:
«آیا سیستم مطابق Requirements عمل میکند؟»
در Acceptance Testing میپرسیم:
«آیا این محصول نیاز Customer یا Business را برآورده میکند و میتوان آن را پذیرفت؟»
بنابراین Acceptance Testing بر پذیرش محصول بر اساس معیارهای کسبوکار و پذیرش تمرکز دارد، در حالی که System Testing یکی از سطوح مهم ارزیابی سیستم یکپارچه در برابر Requirements است.
۱۱. انواع System Testing
System Testing یک Test Type واحد نیست؛ بلکه یک Test Level است که میتواند تستهای مختلفی را در Scope خود داشته باشد. نوع تستی که در این سطح انجام میشود، به Requirements، ریسکها و Scope پروژه بستگی دارد.
بهطور کلی، مهمترین Test Typeهایی که میتوانند در سطح سیستم مورد استفاده قرار گیرند عبارتاند از:
۱. Functional System Testing
در این نوع تست بررسی میشود که سیستم چه کاری انجام میدهد و آیا رفتار آن با Functional Requirements مطابقت دارد یا خیر.
برای مثال:
- Login و Logout
- Registration
- Search
- Shopping Cart
- Checkout
- Payment
- Order Management
- Notification
- Business Rules
- Error Handling
برای مثال، در یک فروشگاه اینترنتی میتوان بررسی کرد که پس از پرداخت موفق، Order با اطلاعات صحیح ایجاد شود و وضعیت آن به مقدار مورد انتظار تغییر کند.
۲. Non-Functional System Testing
در این بخش بررسی میشود که سیستم چگونه کار میکند و آیا ویژگیهای کیفی مورد انتظار را برآورده میکند یا خیر.
بسته به Requirements و Scope پروژه، مواردی مانند زیر میتوانند در سطح سیستم مورد بررسی قرار گیرند:
- Performance Testing — بررسی رفتار سیستم از نظر کارایی و پاسخگویی
- Security Testing — بررسی الزامات و کنترلهای امنیتی
- Usability Testing — بررسی سهولت استفاده
- Compatibility Testing — بررسی عملکرد در محیطها و پلتفرمهای مختلف
- Reliability Testing — بررسی قابلیت اطمینان
- Recovery Testing — بررسی رفتار سیستم پس از Failure
البته این موارد الزاماً در هر پروژه یا در هر اجرای System Testing انجام نمیشوند و ممکن است برخی از آنها توسط تیمها یا فرآیندهای تخصصی جداگانه بررسی شوند.
۳. End-to-End Testing در سطح سیستم
یکی از رویکردهای رایج در ارزیابی سیستم، بررسی Business Workflowهای کامل است.
برای مثال:
Login → Search → Cart → Checkout → Payment → Order
در اینجا هدف بررسی یک جریان کامل از ابتدا تا انتهاست تا مشخص شود اجزای مختلف سیستم در قالب یک فرآیند واقعی، رفتار مورد انتظار را ارائه میدهند.
البته همانطور که در بخش قبل گفتیم، End-to-End Testing با System Testing مترادف نیست؛ یک تست میتواند در سطح System انجام شود و در عین حال یک End-to-End Scenario باشد.
۴. Regression Testing در سطح سیستم
بعد از ایجاد تغییر در نرمافزار، لازم است بررسی شود که قابلیتهای قبلی سیستم همچنان درست کار میکنند.
برای مثال، اگر منطق Payment تغییر کند، ممکن است علاوه بر تست Payment، بخشهایی مانند:
Checkout → Order → Notification
نیز دوباره بررسی شوند.
بنابراین Regression Testing میتواند در سطح System نیز انجام شود و برای بررسی تأثیر تغییرات بر رفتار کلی سیستم اهمیت زیادی دارد.
نکته مهم درباره «انواع System Testing»
نباید تصور کنیم که یک فهرست ثابت و رسمی از «انواع System Testing» وجود دارد که تمام پروژهها دقیقاً از همان استفاده میکنند.
System Testing یک Test Level است و میتواند بر اساس نیاز پروژه، تستهای مختلفی را شامل شود.
برای مثال:
System Testing → Functional + Performance + Security + Compatibility
یا در یک پروژه دیگر:
System Testing → Functional + Regression + Compatibility
بنابراین بهتر است به جای حفظ کردن یک لیست ثابت، ابتدا Requirements و Riskها را بررسی کنیم و سپس مشخص کنیم چه تستهایی باید در سطح سیستم انجام شوند.
یک اشتباه رایج
گاهی اصطلاحاتی مانند Functional Testing، Performance Testing یا Security Testing بهعنوان «انواع System Testing» معرفی میشوند. این بیان میتواند گمراهکننده باشد.
دقیقتر است بگوییم:
Functional، Performance، Security و موارد مشابه Test Type هستند؛ System Testing یک Test Level است که میتواند این Test Typeها را در Scope خود داشته باشد.
این تفاوت مفهومی، برای درک درست ساختار تست نرمافزار بسیار مهم است.
۱۲. System Testing در Agile
در رویکردهای سنتی ممکن بود System Testing بهعنوان فعالیتی نسبتاً مستقل در مراحل پایانی توسعه نرمافزار دیده شود؛ اما در Agile، توسعه و تست بهصورت تکرارشونده انجام میشوند و System Testing نیز میتواند در طول چندین Sprint و برای Incrementهای مختلف محصول انجام شود.
به زبان ساده، در Agile منتظر نمیمانیم تا کل محصول در پایان پروژه ساخته شود و سپس System Testing را شروع کنیم.
System Testing در Sprint چگونه انجام میشود؟
فرض کنید تیم در یک Sprint قابلیت ثبت سفارش را توسعه میدهد.
پس از آمادهشدن Increment مربوطه، تیم میتواند System Testing را برای بخشهای مرتبط انجام دهد:
Product Selection → Cart → Checkout → Payment → Order
اگر Sprint بعدی قابلیت لغو سفارش را اضافه کند، System Testing نیز با توجه به تغییرات جدید و تأثیر آنها بر قابلیتهای قبلی دوباره انجام میشود.
بنابراین System Testing در Agile میتواند یک فعالیت تکرارشونده و مستمر باشد.
ارتباط System Testing با Definition of Done
در بسیاری از تیمهای Agile، تست بخشی از Definition of Done (DoD) است.
یعنی یک User Story صرفاً به دلیل اینکه کد آن نوشته شده، Done محسوب نمیشود؛ بلکه ممکن است لازم باشد:
- تستهای مربوطه اجرا شده باشند.
- Acceptance Criteria برآورده شده باشند.
- Defectهای مهم برطرف شده باشند.
- Regression لازم انجام شده باشد.
- قابلیت در محیط مناسب بررسی شده باشد.
در چنین شرایطی، System Testing میتواند بخشی از فرآیند اطمینان از آمادهبودن Increment باشد.
System Testing و Acceptance Criteria
Acceptance Criteria میتواند ورودی مهمی برای طراحی System Test باشد.
برای مثال:
کاربر باید بتواند پس از پرداخت موفق، سفارش خود را در بخش «سفارشهای من» مشاهده کند.
تستر میتواند یک System Test طراحی کند که کل جریان زیر را بررسی کند:
Login → Select Product → Cart → Checkout → Payment → Order → My Orders
در اینجا Acceptance Criteria به تعیین رفتار مورد انتظار کمک میکند.
System Testing و Continuous Testing
در تیمهایی که از CI/CD و Continuous Testing استفاده میکنند، بخشی از System Testها میتواند بهصورت خودکار اجرا شود.
Code Change → Build → Automated Tests → System/E2E Tests → Deployment
این رویکرد باعث میشود مشکلات زودتر شناسایی شوند و تیم مجبور نباشد تستهای مرتبط با سیستم را فقط پیش از Release انجام دهد.
البته همه System Testها الزاماً برای Automation یا اجرای مداوم مناسب نیستند. تستر باید بر اساس هزینه، ریسک، پایداری و ارزش تست درباره Automation و زمان اجرای آن تصمیم بگیرد.
نقش تستر در System Testing در Agile
در Agile، تستر نباید فقط پس از پایان Development وارد فرآیند شود. تستر میتواند از ابتدای Sprint در فعالیتهایی مانند موارد زیر مشارکت داشته باشد:
- بررسی Requirements
- بررسی User Story
- تحلیل Acceptance Criteria
- شناسایی Riskها
- طراحی Test Scenario
- آمادهسازی Test Data
- اجرای تست
- بررسی Defect
- Regression Testing
در نتیجه، System Testing در Agile میتواند بخشی از یک فرآیند Continuous Testing باشد، نه یک مرحله جدا و دیرهنگام.
نکته مهم
Agile به این معنی نیست که System Testing حذف میشود یا فقط به تستهای کوچک محدود میشویم.
برعکس، با افزایش تعداد Incrementها و تغییرات مداوم سیستم، اهمیت بررسی رفتار کل سیستم پس از تغییرات بیشتر میشود.
در Agile، System Testing از یک فعالیت انتهایی به یک فعالیت تکرارشونده تبدیل میشود که همگام با توسعه و تغییرات محصول انجام میگیرد.
۱۳. System Testing در Automation
با بزرگتر شدن نرمافزار و افزایش تعداد قابلیتها، اجرای دستی تمام سناریوهای System Testing در هر Release میتواند زمانبر و پرهزینه باشد. به همین دلیل، بخشی از System Testing را میتوان با Test Automation انجام داد.
اما یک نکته مهم وجود دارد:
System Testing و Test Automation دو مفهوم متفاوت هستند.
System Testing یک Test Level است، در حالی که Automation یک روش اجرای تست است. بنابراین System Testها میتوانند بهصورت Manual یا Automated اجرا شوند.
چه System Testهایی برای Automation مناسبتر هستند؟
معمولاً سناریوهایی که ویژگیهای زیر را دارند، گزینههای مناسبی برای Automation هستند:
- زیاد تکرار میشوند.
- نتیجه مشخص و قابل پیشبینی دارند.
- در Regression Testing مرتب اجرا میشوند.
- نسبتاً پایدار هستند.
- اجرای دستی آنها زمان زیادی میگیرد.
برای مثال، در یک فروشگاه اینترنتی میتوان جریان زیر را بهصورت Automated System/E2E Test اجرا کرد:
Login → Search Product → Add to Cart → Checkout → Order Creation
ابزارهای Automation در System Testing
بسته به نوع سیستم و Scope تست، ابزارهای مختلفی میتوانند برای Automation مورد استفاده قرار گیرند. برای مثال:
- Playwright برای Web UI و E2E Testing
- Selenium برای Web Automation
- ابزارهای API Testing برای بررسی جریانهای مبتنی بر API
- ابزارهای Performance Testing برای بررسی رفتار سیستم تحت Load
در پروژههای واقعی ممکن است چند ابزار مختلف در کنار یکدیگر مورد استفاده قرار گیرند.
System Testing در CI/CD
یکی از مزایای Automation این است که بخشی از System Testها میتوانند در Pipelineهای CI/CD اجرا شوند.
Code Change → Build → Unit Tests → Integration Tests → System/E2E Tests → Deployment
در این حالت، تغییرات نرمافزار میتوانند بهصورت خودکار بررسی شوند و در صورت بروز مشکل، تیم سریعتر از آن مطلع شود.
آیا باید تمام System Testing را Automated کنیم؟
خیر. هدف از Test Automation این نیست که تمام System Testing را به تستهای خودکار تبدیل کنیم.
برخی فعالیتها به دلیل ماهیت خود برای Automation مناسب نیستند؛ برای مثال:
- Exploratory Testing
- بررسیهای پیچیده UX و Usability
- سناریوهایی که مرتب تغییر میکنند
- تستهایی که نیاز به قضاوت انسانی دارند
- تستهایی که هزینه Automation آنها از ارزششان بیشتر است
بنابراین هدف، Automate کردن همه چیز نیست؛ بلکه باید Automation را در جاهایی به کار برد که بیشترین ارزش را ایجاد میکند.
System Testing و Test Pyramid
در طراحی معماری تست، نباید تمام پوشش تست را به تعداد زیادی UI یا E2E Test تبدیل کنیم. تستهای سطح پایینتر مانند Unit و Integration معمولاً سریعتر و کمهزینهتر هستند، در حالی که تستهای System/E2E ممکن است زمان اجرا و هزینه نگهداری بیشتری داشته باشند.
به همین دلیل، System/E2E Testها باید با توجه به ریسک و ارزش کسبوکار با دقت انتخاب شوند.
در یک نگاه ساده میتوان این موضوع را چنین نمایش داد:
System / E2E
▲
/ \
/ \
Integration
▲
/ \
/ \
Unitالبته Test Pyramid یک اصل طراحی است و نباید آن را بهعنوان یک قانون ثابت با نسبتهای مشخص برای تمام پروژهها در نظر گرفت.
نتیجه
Automation میتواند System Testing را سریعتر، قابلتکرارتر و مناسبتر برای Regression و CI/CD کند؛ اما Automation جایگزین تستر نیست و قرار نیست تمام System Testing به Automated Test تبدیل شود.
بهترین رویکرد معمولاً ترکیبی از Automated Testing + Manual Testing + Exploratory Testing است.
۱۴. System Testing؛ دستی یا خودکار؟
یکی از سؤالهای مهم در System Testing این است که آیا تستهای سیستم باید بهصورت Manual انجام شوند یا آنها را Automate کنیم.
پاسخ کوتاه این است:
هیچکدام بهتنهایی بهترین انتخاب نیستند؛ ترکیبی از Manual Testing و Test Automation معمولاً رویکرد مناسبتری است.
انتخاب بین این دو به عواملی مانند نوع سناریو، میزان تکرار، پایداری سیستم، ریسک و هزینه نگهداری تست بستگی دارد.
Manual System Testing
در Manual System Testing، تستر سناریوها را بدون استفاده از Scriptهای خودکار اجرا میکند.
این روش برای مواردی مانند زیر ارزش زیادی دارد:
- Exploratory Testing
- سناریوهای جدید و ناشناخته
- بررسی تجربه کاربری
- قابلیتهایی که مرتب تغییر میکنند
- بررسی رفتارهای غیرمنتظره
- تستهایی که نیاز به قضاوت انسانی دارند
برای مثال، اگر یک Feature جدید به سیستم اضافه شده باشد، تستر میتواند ابتدا با Exploratory Testing رفتار آن را بررسی کند و فقط به سناریوهای از قبل تعریفشده محدود نباشد.
Automated System Testing
در Automated System Testing، اجرای Test Caseها توسط ابزارها و Scriptهای خودکار انجام میشود.
این روش برای سناریوهایی که:
- مرتب تکرار میشوند.
- نسبتاً پایدار هستند.
- نتیجه مشخصی دارند.
- در Regression Testing زیاد استفاده میشوند.
- اجرای دستی آنها زمان زیادی میگیرد.
مناسبتر است.
مثلاً میتوان یک سناریوی ثابت مانند زیر را Automate کرد:
Login → Add Product → Checkout → Payment → Verify Order
سپس همین تست را میتوان در هر Release یا در CI Pipeline اجرا کرد.
مقایسه Manual و Automated System Testing
| ویژگی | Manual | Automated |
|---|---|---|
| سرعت اجرای تستهای تکراری | کمتر | بیشتر |
| Exploratory Testing | بسیار مناسب | نامناسب |
| قضاوت انسانی | مناسب | محدود |
| Regression Testing | زمانبر | بسیار مناسب |
| هزینه اولیه | معمولاً کمتر | بیشتر |
| هزینه نگهداری | معمولاً کمتر | ممکن است بیشتر باشد |
| اجرای مکرر | مناسب نیست | بسیار مناسب |
| CI/CD | محدود | بسیار مناسب |
آیا Automation جایگزین Manual Testing میشود؟
خیر. یکی از اشتباهات رایج این است که تصور کنیم با Automated شدن System Testing، دیگر نیازی به تست دستی وجود ندارد.
Automation بیشتر برای اجرای قابلتکرار و قابلپیشبینی مناسب است؛ در حالی که تستر میتواند رفتار سیستم را از زاویههای جدید بررسی کند و مشکلاتی را پیدا کند که Script از قبل برای آنها طراحی نشده است.
مثلاً یک Automated Test ممکن است تأیید کند که دکمه «ثبت سفارش» قابل کلیک است و Order ایجاد میشود؛ اما تستر ممکن است در حین بررسی متوجه شود که:
- متن پیام موفقیت برای کاربر نامفهوم است.
- در یک شرایط خاص امکان چند بار کلیک روی دکمه وجود دارد.
- ترتیب اطلاعات در Checkout گیجکننده است.
- رفتار سیستم در یک سناریوی غیرمنتظره مناسب نیست.
بهترین رویکرد چیست؟
بهتر است System Testing را به شکل یک ترکیب هوشمندانه از Automation و Manual Testing طراحی کنیم.
Automated Testing برای مواردی مانند:
- Regression Testing
- Critical Business Flows
- تستهای تکراری
- Smoke و Sanity Testهای قابلخودکارسازی
- اجرای تست در CI/CD
Manual Testing برای مواردی مانند:
- Exploratory Testing
- قابلیتهای جدید
- Usability Testing
- سناریوهای پیچیده
- بررسی رفتارهای غیرمنتظره
بنابراین سؤال درست این نیست که:
«Manual بهتر است یا Automation؟»
بلکه باید پرسید:
«کدام بخش از System Testing بیشترین ارزش را از Automation میگیرد و کدام بخش هنوز به قضاوت و خلاقیت تستر نیاز دارد؟»
این نگاه باعث میشود Automation بهعنوان ابزار افزایش اثربخشی تستر استفاده شود، نه جایگزین کامل آن.
۱۵. System Test Environment
برای اجرای System Testing، فقط داشتن Test Case کافی نیست. سیستم باید در یک Test Environment مناسب اجرا شود تا تستر بتواند رفتار آن را در شرایط موردنظر بررسی کند.
System Test Environment محیطی است که نرمافزار و وابستگیهای موردنیاز آن در آن مستقر شدهاند تا System Testing در آن انجام شود.
اجزای یک System Test Environment
بسته به معماری و نوع پروژه، Test Environment میتواند شامل بخشهای مختلفی باشد، از جمله:
- Application یا Web Application
- Backend Services
- Database
- APIها
- Authentication Service
- Payment Gateway
- Email/SMS Service
- File Storage
- Message Queue
- Third-Party Services
- Test Accounts
- Test Data
- Configurationهای موردنیاز
برای مثال، در یک فروشگاه اینترنتی ممکن است ساختار محیط تست شامل بخشهای زیر باشد:
Web Application → Backend → Database
Payment Gateway + Notification Service + Authentication Service
تستر باید بتواند سیستم و وابستگیهای موردنیاز آن را در شرایطی مناسب برای سناریوهای موردنظر بررسی کند.
چرا Test Environment اهمیت دارد؟
فرض کنید یک Test Case در محیط تست با موفقیت اجرا میشود، اما Environment با شرایط واقعی سیستم تفاوت زیادی دارد.
برای مثال:
- نسخه متفاوتی از Database استفاده شده باشد.
- APIهای خارجی در محیط تست Mock شده باشند، در حالی که Production از سرویس واقعی استفاده میکند.
- Configuration متفاوت باشد.
- Browser یا Device مورد استفاده با محیط واقعی متفاوت باشد.
- سرویسهای وابسته در محیط تست رفتار متفاوتی داشته باشند.
در چنین شرایطی ممکن است نتیجه تست بهطور کامل نشاندهنده رفتار واقعی سیستم نباشد.
نتیجه تست فقط به Test Case وابسته نیست؛ شرایطی که تست در آن اجرا میشود نیز میتواند روی نتیجه تأثیر بگذارد.
آیا Test Environment باید مشابه Production باشد؟
لزوماً نه. اما Environment باید برای هدف و Scope تست مناسب باشد و در بخشهایی که روی نتیجه تست تأثیر میگذارند، تا حد امکان به شرایط واقعی نزدیک باشد.
برای مثال، اگر هدف بررسی Compatibility باشد، باید Browserها و Deviceهای مورد پشتیبانی در Environment در دسترس باشند.
اگر هدف Performance Testing باشد، Configuration، منابع سختافزاری و شرایط شبکه اهمیت بیشتری پیدا میکنند.
در Functional System Testing نیز مهم است که Application، Database، APIها و سرویسهای موردنیاز، رفتار مناسب و قابلکنترلی داشته باشند.
بنابراین میزان شباهت Test Environment به Production باید بر اساس هدف تست، ریسک و Scope پروژه تعیین شود.
Test Environment و Third-Party Services
در سیستمهای مدرن، بسیاری از Applicationها به سرویسهای خارجی وابستهاند.
- Payment Provider
- Email Provider
- SMS Provider
- Identity Provider
- Maps API
- Cloud Storage
در System Testing باید مشخص شود این وابستگیها چگونه تست خواهند شد.
گاهی استفاده از Mock یا Stub مناسبتر است و گاهی لازم است سیستم با یک سرویس واقعی یا Test/Sandbox Environment آن سرویس ارتباط برقرار کند.
انتخاب روش به هدف تست، هزینه، ریسک و میزان کنترلپذیری Environment بستگی دارد.
Test Environment و Test Data
Environment بدون داده مناسب، برای بسیاری از System Testها عملاً قابل استفاده نیست.
برای مثال، برای تست فرآیند خرید ممکن است به موارد زیر نیاز داشته باشیم:
- User Account
- Product
- Inventory
- Address
- Discount
- Payment Data
- Order History
به همین دلیل Test Environment و Test Data ارتباط بسیار نزدیکی با یکدیگر دارند و هر دو باید پیش از اجرای تستهای مهم آماده باشند.
مشکلات رایج در System Test Environment
برخی مشکلات رایج عبارتاند از:
- Environment در دسترس نیست.
- Configuration اشتباه است.
- دادههای تست ناقص یا نامعتبر هستند.
- یک سرویس وابسته Down است.
- نسخه Application با نسخه مورد انتظار متفاوت است.
- Environment بین اجرای تستها تغییر میکند.
- شرایط Environment با محیط واقعی تفاوت زیادی دارد.
این مشکلات میتوانند باعث شوند نتیجه تست بهدرستی وضعیت واقعی سیستم را نشان ندهد و حتی در برخی شرایط به False Positive یا False Negative منجر شوند.
نتیجه
یک System Test خوب فقط به Test Case خوب نیاز ندارد؛ بلکه به Environment قابلاعتماد و قابلکنترل نیز نیاز دارد.
به همین دلیل، آمادهسازی و مدیریت Test Environment باید بخشی از برنامهریزی System Testing باشد، نه کاری که در آخرین لحظه انجام شود.
۱۶. System Testing و Test Data
Test Data یکی از عوامل مهم در System Testing است. حتی اگر Test Case بهدرستی طراحی شده باشد، داده نامناسب میتواند باعث شود تست نتیجه واقعی و قابلاعتمادی نداشته باشد.
برای مثال، اگر بخواهیم فرآیند خرید یک فروشگاه اینترنتی را تست کنیم، فقط داشتن یک Test Case با عنوان «ثبت سفارش» کافی نیست. باید دادههایی مانند کاربر، محصول، موجودی، قیمت، آدرس و اطلاعات پرداخت نیز آماده باشند.
چرا Test Data اهمیت دارد؟
در System Testing، بسیاری از رفتارهای سیستم به دادههایی وابسته هستند که در بخشهای مختلف استفاده میشوند.
Product → Cart → Checkout → Payment → Order
اگر Product موجود نباشد یا Inventory مقدار اشتباهی داشته باشد، نتیجه تست ممکن است بهجای یک مشکل واقعی در سیستم، ناشی از داده نامناسب باشد.
بنابراین باید بتوانیم تشخیص دهیم:
آیا Test Fail شده چون سیستم مشکل دارد یا چون Test Data اشتباه بوده است؟
انواع Test Data در System Testing
بسته به سناریوی موردنظر، میتوان از انواع مختلف داده استفاده کرد.
Valid Test Data
دادههایی که باید توسط سیستم پذیرفته شوند.
- Username معتبر
- Email معتبر
- محصول موجود
- اطلاعات صحیح پرداخت
هدف، بررسی رفتار صحیح سیستم در شرایط عادی است.
Invalid Test Data
دادههایی که انتظار میرود سیستم آنها را رد کند.
- Email با فرمت اشتباه
- رمز عبور نامعتبر
- مقدار منفی
- کد تخفیف نامعتبر
- اطلاعات ناقص
در این حالت بررسی میکنیم آیا سیستم داده نامعتبر را بهدرستی مدیریت میکند یا خیر.
Boundary Test Data
دادههایی که در نزدیکی مرزهای تعریفشده قرار دارند.
مثلاً اگر تعداد مجاز خرید یک محصول بین ۱ تا ۱۰ باشد، میتوان مقادیر زیر را بررسی کرد:
0، 1، 10، 11
این دادهها میتوانند مشکلات مربوط به Boundary Condition را آشکار کنند.
Large Test Data
دادههایی با حجم زیاد که برای بررسی رفتار سیستم در شرایط حجمی مورد استفاده قرار میگیرند.
- تعداد زیاد محصولات
- تعداد زیاد سفارشها
- فایل بزرگ
- لیست طولانی کاربران
این نوع داده میتواند در بررسی برخی Requirements مربوط به Performance و Scalability نیز کاربرد داشته باشد.
Duplicate Test Data
دادههای تکراری نیز میتوانند رفتار سیستم را مشخص کنند.
مثلاً:
- آیا یک کاربر میتواند دوبار با یک Email ثبتنام کند؟
- اگر یک درخواست ثبت سفارش دوبار ارسال شود، سیستم چه رفتاری دارد؟
Test Data برای سناریوهای منفی
یکی از اشتباهات رایج این است که برای System Testing فقط دادههای معتبر آماده کنیم.
درحالیکه بسیاری از مشکلات سیستم زمانی مشخص میشوند که داده غیرمنتظره یا شرایط نامطلوب دریافت میکند.
برای مثال:
- موجودی محصول = 0
- Payment Status = Failed
- Discount Code = Expired
تستر باید بررسی کند که سیستم در چنین شرایطی مطابق Requirements رفتار میکند.
Test Data و Privacy
در System Testing همیشه نباید از داده واقعی کاربران استفاده کرد. اگر استفاده از دادههای Production برای تست ضروری باشد، باید مطابق سیاستها و الزامات پروژه از روشهایی مانند موارد زیر برای محافظت از اطلاعات استفاده شود:
- Synthetic Data
- Data Masking
- Anonymization
هدف این است که داده موردنیاز برای تست فراهم شود، بدون اینکه اطلاعات حساس کاربران در معرض خطر قرار گیرد.
Test Data باید قابل تکرار باشد
یکی از ویژگیهای مهم Test Data مناسب، Repeatability است.
اگر یک Test Case امروز با داده خاصی Pass شود، بهتر است بتوانیم همان شرایط را دوباره ایجاد کنیم و تست را تکرار کنیم.
User = Test User
Product = Product A
Stock = 10
Discount = 20%داشتن داده مشخص و قابل تکرار کمک میکند در صورت Fail شدن تست، شرایط قبلی را دوباره ایجاد و مشکل را بررسی کنیم.
نتیجه
Test Data صرفاً «چند داده برای پر کردن فرمها» نیست.
در System Testing، داده بخشی از شرایط تست است و میتواند مستقیماً روی نتیجه Test تأثیر بگذارد.
بنابراین برای System Testing موفق باید علاوه بر طراحی Test Case، مشخص کنیم:
چه دادهای، در چه شرایطی و با چه مقداری باید وارد سیستم شود تا بتوانیم رفتار موردنظر را بهدرستی ارزیابی کنیم؟
۱۷. System Testing چه زمانی انجام میشود؟
یکی از تصورات اشتباه درباره System Testing این است که تست سیستم فقط در پایان فرآیند توسعه و درست قبل از Release انجام میشود.
در روشهای سنتی توسعه ممکن است System Testing بهصورت یک مرحله مشخص پس از Integration Testing قرار بگیرد، اما در رویکردهای مدرن مانند Agile و Continuous Testing، تست سیستم میتواند در طول توسعه و برای Incrementهای مختلف محصول بارها انجام شود.
System Testing معمولاً بعد از یکپارچهشدن اجزای سیستم انجام میشود
در یک مدل ساده از فرآیند توسعه میتوان این ترتیب را در نظر گرفت:
Development → Unit Testing → Integration Testing → System Testing → Acceptance Testing → Release
پس از اینکه اجزای موردنیاز سیستم یکپارچه شدند و یک Build قابل تست در اختیار تیم قرار گرفت، System Testing مرتبط با آن بخش میتواند آغاز شود.
البته این به معنی آن نیست که تمام Unit و Integration Testها باید یکبار برای همیشه تمام شده باشند. در پروژههای مدرن، این تستها میتوانند همزمان و بهصورت تکرارشونده اجرا شوند.
System Testing در Agile
در Agile، محصول بهصورت Incremental توسعه پیدا میکند و System Testing نیز میتواند متناسب با Incrementهای قابل تست انجام شود.
فرض کنید در Sprint اول قابلیت Login توسعه داده شده است. پس از آمادهشدن Increment میتوان System Testهای مرتبط با آن را اجرا کرد.
در Sprint بعد قابلیت Shopping Cart اضافه میشود:
Login + Cart
و System Testing با توجه به قابلیت جدید و تأثیر آن بر بخشهای قبلی دوباره انجام میشود.
در Sprint بعد قابلیت Checkout اضافه میشود:
Login + Cart + Checkout
بنابراین System Testing در Agile میتواند تکرارشونده و همگام با توسعه محصول باشد.
System Testing قبل از Release
هرچه به Release نزدیکتر میشویم، System Testing اهمیت بیشتری پیدا میکند؛ زیرا باید مطمئن شویم مجموعه تغییرات انجامشده، سیستم را در وضعیت مورد انتظار قرار داده است.
در این مرحله، بسته به Release Scope و ریسکهای موجود، ممکن است تستهایی مانند موارد زیر اجرا شوند:
- Critical Business Flows
- Regression Testing
- End-to-End Scenarios
- Compatibility Testing
- Performance Testing
- سایر تستهای موردنیاز بر اساس Release Scope
آیا باید بعد از هر تغییر، System Testing کامل انجام شود؟
لزوماً نه.
اجرای تمام System Testها بعد از هر تغییر ممکن است زمان و منابع زیادی مصرف کند. به همین دلیل، تیم تست معمولاً بر اساس Risk، Impact و نوع تغییر تصمیم میگیرد چه تستهایی اجرا شوند.
برای مثال، اگر فقط ظاهر یک صفحه تغییر کرده باشد، احتمالاً نیازی به اجرای تمام System Test Suite نیست.
اما اگر منطق Payment تغییر کرده باشد، تستهای مرتبط با:
Checkout → Payment → Order → Notification
اهمیت بیشتری پیدا میکنند.
System Testing در Continuous Testing
در تیمهایی که از Continuous Testing استفاده میکنند، بخشی از System Testها میتوانند بهصورت خودکار و مکرر اجرا شوند.
Code Change → Build → Automated Tests → System Tests → Deployment
این رویکرد باعث میشود مشکلات سیستم زودتر شناسایی شوند و تست به یک مرحله جداگانه در پایان پروژه محدود نشود.
پس بهترین زمان برای System Testing چه زمانی است؟
پاسخ به نوع پروژه، مدل توسعه و Scope سیستم بستگی دارد؛ اما بهطور کلی:
هر زمان که یک Increment قابل تست از سیستم وجود داشته باشد و اجزای موردنیاز آن در کنار یکدیگر قرار گرفته باشند، میتوان System Testing مرتبط با آن Increment را انجام داد.
در پروژههای Agile این اتفاق میتواند در هر Sprint تکرار شود و در نزدیکی Release نیز مجموعهای گستردهتر از System Testها اجرا شود.
بنابراین بهتر است System Testing را یک فعالیت تکرارشونده در چرخه توسعه بدانیم، نه صرفاً آخرین مرحله قبل از انتشار نرمافزار.
۱۸. System Testing در SDLC
System Testing را میتوان در مدلهای مختلف Software Development Life Cycle (SDLC) مشاهده کرد، اما زمانبندی و نحوه اجرای آن به مدل توسعه پروژه بستگی دارد.
برای مثال، System Testing در یک پروژه Waterfall ممکن است ساختار متفاوتی نسبت به یک پروژه Agile داشته باشد.
System Testing در مدل Waterfall
در مدل سنتی Waterfall، مراحل توسعه معمولاً بهصورت نسبتاً خطی انجام میشوند:
Requirements → Design → Development → Integration → System Testing → Acceptance → Release
در این مدل، System Testing معمولاً پس از تکمیل Development و Integration آغاز میشود.
به همین دلیل، System Testing میتواند نسبت به مراحل دیگر بهعنوان یک مرحله مشخص و متمرکز در چرخه پروژه دیده شود.
System Testing در V-Model
ارتباط System Testing با V-Model اهمیت ویژهای دارد. در این مدل، فعالیتهای Development و Testing از همان مراحل اولیه به یکدیگر مرتبط میشوند.
بهصورت ساده میتوان این ارتباط را چنین نشان داد:
- Requirements ↔ Acceptance Testing
- System Requirements ↔ System Testing
- Architecture/Design ↔ Integration Testing
- Module Design ↔ Unit Testing
در این مدل، System Testing ارتباط مستقیمی با System Requirements دارد. یعنی نیازمندیها در مراحل اولیه تحلیل میشوند و سپس Test Caseها و Test Scenarioهای مناسب برای بررسی تحقق آنها طراحی میشوند.
به همین دلیل، Requirements Traceability در System Testing اهمیت زیادی پیدا میکند.
System Testing در Agile
در Agile، SDLC یک جریان کاملاً خطی نیست. توسعه و تست در چرخههای کوتاه و تکرارشونده انجام میشوند.
Plan → Develop → Test → Review → Increment
در هر Sprint ممکن است بخشی از سیستم توسعه پیدا کند و System Testing مرتبط با آن نیز انجام شود.
در نتیجه System Testing میتواند در طول چرخه عمر محصول بارها تکرار شود.
System Testing در Continuous Delivery
در تیمهایی که از Continuous Integration و Continuous Delivery استفاده میکنند، بخشی از System Testهای خودکار میتوانند در Pipeline قرار بگیرند.
Commit → Build → Unit Tests → Integration Tests → System/E2E Tests → Deployment
در این حالت System Testing میتواند بهصورت مکرر و خودکار اجرا شود.
البته تمام System Testها الزاماً نباید در هر Pipeline اجرا شوند. انتخاب تستها میتواند بر اساس سرعت، هزینه، ریسک و اهمیت سناریو انجام شود.
ارتباط System Testing با Requirements
یکی از مهمترین ارتباطهای System Testing با SDLC، Requirements Traceability است.
بهتر است بتوانیم ارتباط بین نیازمندی، تست و نتیجه آن را دنبال کنیم:
Requirement → Test Scenario → Test Case → Test Result → Defect
برای مثال:
Requirement: کاربر باید بتواند پس از پرداخت موفق، سفارش خود را مشاهده کند.
Test Scenario: ثبت سفارش و پرداخت موفق
Test Case: بررسی نمایش Order پس از پرداخت
Test Result: Pass / Fail
اگر Test Fail شود:
→ Defect Report
این زنجیره کمک میکند مشخص باشد هر Requirement چگونه مورد بررسی قرار گرفته و نتیجه تست آن چه بوده است.
آیا System Testing فقط مربوط به یک مرحله از SDLC است؟
خیر. نحوه قرار گرفتن System Testing در SDLC به مدل توسعه پروژه بستگی دارد.
- در Waterfall ممکن است System Testing عمدتاً بهعنوان یک مرحله مشخص بعد از Integration دیده شود.
- در V-Model ارتباط آن با System Requirements از مراحل اولیه مشخص میشود.
- در Agile System Testing بهصورت تکرارشونده در طول Sprintها انجام میشود.
- در Continuous Delivery بخشی از System Testها میتوانند بهصورت مداوم و خودکار اجرا شوند.
بنابراین بهتر است System Testing را صرفاً به یک نقطه ثابت در SDLC محدود نکنیم؛ بلکه آن را فعالیتی برای ارزیابی سیستم در برابر نیازمندیها، متناسب با مدل توسعه پروژه در نظر بگیریم.
۱۹. System Testing و Regression Testing
System Testing و Regression Testing دو مفهوم متفاوت هستند، اما در پروژههای واقعی ارتباط نزدیکی با یکدیگر دارند.
یکی از دلایل آن این است که تغییر در یک بخش از سیستم میتواند روی قابلیتهایی که قبلاً درست کار میکردند تأثیر بگذارد.
Regression Testing چیست؟
Regression Testing به بررسی مجدد بخشهای قبلی نرمافزار گفته میشود تا مشخص شود تغییرات جدید باعث ایجاد مشکل در قابلیتهای موجود نشدهاند.
سؤال اصلی در Regression Testing این است:
آیا تغییرات جدید چیزی را که قبلاً درست کار میکرد، خراب کردهاند؟
در حالی که در System Testing سؤال اصلی این است:
آیا سیستم یکپارچه مطابق Requirements عمل میکند؟
یک مثال ساده
فرض کنید در یک فروشگاه اینترنتی، منطق Payment تغییر کرده است.
تستر ابتدا ممکن است بررسی کند که:
Payment → Success → Order Created
بهدرستی کار میکند. این میتواند بخشی از System Testing یا Retesting مربوط به تغییر جدید باشد.
اما تغییر Payment ممکن است روی بخشهای دیگری نیز تأثیر گذاشته باشد:
- Order Status
- Inventory
- Invoice
- Email Notification
- Refund
- Order History
بنابراین باید بخشی از سناریوهای قبلی نیز دوباره اجرا شوند. این قسمت Regression Testing است.
آیا Regression Testing بخشی از System Testing است؟
این دو مفهوم در دو دسته متفاوت قرار میگیرند:
System Testing → Test Level
Regression Testing → Test Type / Test Approach
بنابراین میتوان Regression Testing را در سطح System انجام داد.
برای مثال، بعد از تغییر Payment، مجموعهای از System Testهای قبلی را دوباره اجرا میکنیم تا مطمئن شویم تغییر جدید روی Business Flowهای موجود تأثیر منفی نگذاشته است.
System Testing بدون Regression Testing کافی است؟
در سیستمهایی که دائماً تغییر میکنند، معمولاً خیر.
فرض کنید هر Sprint چند قابلیت جدید اضافه میشود. اگر فقط قابلیت جدید را تست کنیم، ممکن است مشکلاتی در قابلیتهای قبلی ایجاد شده باشند که شناسایی نشوند.
برای مثال:
Sprint 1: Login
Sprint 2: Cart
Sprint 3: Payment
Sprint 4: Discount
با اضافهشدن Discount ممکن است منطق Cart یا Checkout نیز تحت تأثیر قرار بگیرد.
بنابراین با افزایش تغییرات، Regression Testing اهمیت بیشتری پیدا میکند.
نقش Automation در System Regression Testing
Regression یکی از بهترین حوزهها برای استفاده از Test Automation است.
فرض کنید ۵۰۰ System Test داریم و پس از هر Release اجرای دستی همه آنها چند روز طول میکشد.
اگر سناریوهای مناسب Automate شوند، میتوان بخش قابلتوجهی از آنها را بهصورت مکرر اجرا کرد.
برای مثال:
New Code → Build → Automated Regression → System Tests → Release
این کار بهخصوص در پروژههایی که Releaseهای مکرر دارند بسیار ارزشمند است.
یک نکته مهم
Regression Testing به معنی اجرای تمام Test Caseهای سیستم بعد از هر تغییر نیست.
تیم تست باید بر اساس مواردی مانند موارد زیر مشخص کند چه Test Caseهایی باید وارد Regression Suite شوند:
- Scope تغییر
- Impact Analysis
- Risk
- Criticality
- سابقه Defectها
- وابستگی بین بخشها
خلاصه تفاوت
| ویژگی | System Testing | Regression Testing |
|---|---|---|
| دستهبندی | Test Level | Test Type / Test Approach |
| تمرکز | بررسی سیستم یکپارچه | بررسی تأثیر تغییرات جدید |
| سؤال اصلی | آیا سیستم مطابق Requirements است؟ | آیا چیزی که قبلاً درست بود، خراب شده؟ |
| Scope | میتواند گسترده باشد | بر اساس Impact و Risk انتخاب میشود |
| Automation | برای برخی سناریوها مناسب است | برای تستهای تکرارشونده بسیار ارزشمند است |
بنابراین در یک پروژه واقعی، این دو میتوانند در کنار یکدیگر استفاده شوند:
System Testing بررسی میکند سیستم درست کار میکند؛ Regression Testing بررسی میکند تغییرات جدید باعث خراب شدن قابلیتهای قبلی نشدهاند.
۲۰. چه زمانی System Testing کافی نیست؟
System Testing یکی از مهمترین سطوح تست نرمافزار است، اما بهتنهایی نمیتواند کیفیت کل محصول را تضمین کند.
این موضوع اهمیت زیادی دارد؛ چون گاهی تصور میشود اگر یک سیستم تمام System Testها را با موفقیت پشت سر بگذارد، پس دیگر مشکلی وجود ندارد. در حالی که هر Test Level و Test Type برای پیدا کردن دسته خاصی از مشکلات طراحی شده است.
۱. وقتی مشکل در سطح Unit وجود دارد
ممکن است یک Function یا Class رفتار نادرستی داشته باشد، اما سناریوی System Test هرگز به آن شرایط خاص نرسد.
برای مثال، یک Function مربوط به محاسبه مالیات ممکن است در یک شرایط مرزی اشتباه عمل کند، اما System Test فقط چند سناریوی عمومی را بررسی کند.
اینجا Unit Testing میتواند پوشش دقیقتری ایجاد کند.
۲. وقتی مشکل مربوط به Integration است
System Testing میتواند مشکلات Integration را پیدا کند، اما همیشه بهترین یا سریعترین سطح برای پیدا کردن آنها نیست.
اگر یک API Contract، Data Mapping یا Interface بین دو Service مشکل داشته باشد، Integration Testing میتواند بسیار هدفمندتر آن مشکل را بررسی کند.
۳. وقتی نیاز به بررسی Performance دقیق داریم
ممکن است تمام Functional System Testها Pass شوند، اما سیستم تحت بار زیاد عملکرد مناسبی نداشته باشد.
مثلاً:
سیستم با ۱۰ کاربر بدون مشکل کار میکند، اما با ۱۰,۰۰۰ کاربر Response Time آن بهشدت افزایش پیدا میکند.
در چنین شرایطی به Performance Testing، Load Testing یا Stress Testing تخصصی نیاز داریم.
۴. وقتی نیاز به Security Testing داریم
System Testing معمولی نمیتواند تمام آسیبپذیریهای امنیتی را شناسایی کند.
برای مثال، بررسی اینکه Login کار میکند با بررسی امنیت Authentication، Authorization، Session Management و سایر مسائل امنیتی یکسان نیست.
در این شرایط Security Testing تخصصی موردنیاز است.
۵. وقتی Usability اهمیت دارد
ممکن است سیستم کاملاً مطابق Requirements کار کند، اما استفاده از آن برای کاربر دشوار یا گیجکننده باشد.
برای مثال:
همه دکمهها و قابلیتها درست کار میکنند، اما کاربر نمیتواند بهراحتی مسیر ثبت سفارش را پیدا کند.
System Testing لزوماً جایگزین Usability Testing نمیشود.
۶. وقتی Acceptance توسط Business هنوز انجام نشده است
ممکن است سیستم از نظر فنی مطابق Specification باشد، اما Customer یا Business آن را برای استفاده واقعی مناسب نداند.
بنابراین Acceptance Testing همچنان اهمیت دارد.
۷. وقتی Test Environment با شرایط واقعی تفاوت زیادی دارد
گاهی System Testها در یک Environment محدود اجرا میشوند، اما Production شرایط کاملاً متفاوتی دارد.
برای مثال:
- Database متفاوت
- Configuration متفاوت
- سرویسهای خارجی متفاوت
- حجم داده متفاوت
- Infrastructure متفاوت
در این شرایط موفقیت System Testing لزوماً به معنی موفقیت سیستم در Production نیست.
۸. وقتی Requirements ناقص یا اشتباه هستند
این یکی از مهمترین محدودیتهاست.
فرض کنید سیستم دقیقاً مطابق Requirement پیادهسازی و تست شده باشد، اما خود Requirement یک نیاز مهم Business را در نظر نگرفته باشد.
در این حالت ممکن است:
سیستم مطابق Requirement → Test Pass
اما:
نیاز واقعی Business → Fail
بنابراین System Testing نمیتواند جایگزین Requirements Validation و بررسی نیاز واقعی کسبوکار شود.
System Testing بخشی از یک استراتژی بزرگتر است
کیفیت نرمافزار معمولاً نتیجه یک Test Level یا Test Type خاص نیست.
میتوان آن را بهصورت ساده اینگونه دید:
Unit Testing
برای بررسی واحدهای کوچک
↓
Integration Testing
برای بررسی ارتباط اجزا
↓
System Testing
برای بررسی سیستم یکپارچه
↓
Acceptance Testing
برای بررسی پذیرش محصول
و در کنار آنها:
Performance + Security + Usability + Compatibility + سایر تستهای موردنیاز
بنابراین System Testing بسیار مهم است، اما آخرین خط دفاعی یا تنها راه اثبات کیفیت نرمافزار نیست.
Pass شدن System Testing به این معنی نیست که نرمافزار بدون Bug است؛ فقط نشان میدهد سیستم در محدوده، شرایط و سناریوهایی که تست شدهاند، نتایج مورد انتظار را داشته است.
۲۱. اشتباهات رایج در System Testing
System Testing به دلیل گستردگی Scope میتواند چالشبرانگیز باشد. بسیاری از مشکلاتی که باعث کاهش اثربخشی آن میشوند، نه به ابزار یا تکنولوژی، بلکه به نحوه طراحی و اجرای تستها مربوط هستند.
در ادامه مهمترین اشتباهاتی را که ممکن است در System Testing رخ دهند بررسی میکنیم.
۱. تست کردن فقط Happy Path
یکی از رایجترین اشتباهات این است که فقط مسیر موفق کاربر تست شود.
مثلاً:
Login → Add to Cart → Payment Success → Order Created
اما شرایطی مانند Payment Failure، موجودی صفر، اطلاعات ناقص یا قطع ارتباط با سرویسها بررسی نشوند.
یک System Test مناسب باید علاوه بر سناریوهای مثبت، Negative Scenarioها و شرایط غیرعادی را نیز پوشش دهد.
۲. نادیده گرفتن Requirements
گاهی Test Caseها بر اساس چیزی که تستر تصور میکند سیستم باید انجام دهد نوشته میشوند، نه بر اساس Requirements.
این کار میتواند باعث شود:
- برخی نیازمندیها اصلاً تست نشوند.
- تستهای غیرضروری ایجاد شوند.
- Traceability از بین برود.
بهتر است Test Scenarioها تا حد امکان به Requirements و Acceptance Criteria قابل ردیابی باشند.
۳. تصور اینکه System Testing جایگزین سایر تستهاست
System Testing نمیتواند جای Unit، Integration، Performance یا Security Testing را بهطور کامل بگیرد.
هر سطح و نوع تست هدف خاص خود را دارد.
مثلاً اگر یک مشکل ساده در یک Function وجود داشته باشد، پیدا کردن آن با یک System Test بزرگ ممکن است بسیار پرهزینهتر از پیدا کردن آن در Unit Testing باشد.
۴. تست کردن فقط رابط کاربری
در برخی پروژهها System Testing تقریباً به UI محدود میشود.
در حالی که سیستم ممکن است شامل موارد زیر نیز باشد:
- API
- Database
- Background Jobs
- Message Queue
- External Services
- Scheduled Tasks
بنابراین System Testing باید بر اساس معماری و رفتار واقعی سیستم طراحی شود، نه فقط چیزی که کاربر روی صفحه میبیند.
۵. استفاده از Test Data نامناسب
اگر Test Data اشتباه باشد، نتیجه تست ممکن است قابل اعتماد نباشد.
مثلاً برای تست خرید محصول باید بدانیم:
- Product موجود است؟
- Stock کافی است؟
- قیمت صحیح است؟
- Discount معتبر است؟
- User شرایط لازم را دارد؟
داده نامناسب میتواند باعث Fail شدن Test Case بدون وجود Bug واقعی شود.
۶. نادیده گرفتن وابستگیهای خارجی
سیستمهای مدرن معمولاً به سرویسهای مختلفی وابستهاند.
مثلاً:
Application → Payment Gateway → Bank
اگر رفتار Payment Gateway در Test Environment با Production متفاوت باشد، نتیجه System Testing ممکن است گمراهکننده شود.
بنابراین Third-Party Dependencies باید در Test Strategy در نظر گرفته شوند.
۷. اجرای بیش از حد System/E2E Test
گاهی تیم برای پوشش بیشتر، تعداد زیادی Test Case پیچیده در سطح System یا E2E ایجاد میکند.
این کار میتواند باعث شود:
- اجرای تستها بسیار کند شود.
- نگهداری Testها دشوار شود.
- تستها شکننده شوند.
- Failureها سختتر تحلیل شوند.
بهتر است Test Suite بر اساس Risk و Business Value طراحی شود.
۸. عدم انجام Regression Testing مناسب
پس از تغییرات مهم، ممکن است تیم فقط Feature جدید را تست کند و قابلیتهای قبلی را بررسی نکند.
این کار میتواند باعث شود یک تغییر جدید، بخش دیگری از سیستم را خراب کند و مشکل تا مراحل بعدی باقی بماند.
۹. وابستگی کامل به Automation
Automated Testها بسیار ارزشمند هستند، اما نمیتوانند جای تمام فعالیتهای تستر را بگیرند.
مثلاً Automated Test ممکن است فقط چیزی را بررسی کند که از قبل برای آن Assertion نوشته شده است.
در مقابل، Exploratory Testing میتواند رفتارهای غیرمنتظرهای را کشف کند که در Test Script پیشبینی نشدهاند.
۱۰. نادیده گرفتن Non-Functional Requirements
گاهی تیم تمام تمرکز خود را روی Featureها میگذارد و مواردی مانند Performance، Security، Compatibility، Reliability و Usability را نادیده میگیرد.
اگر چنین ویژگیهایی در Requirements وجود داشته باشند، باید در Test Scope نیز مورد توجه قرار گیرند.
۱۱. تست کردن در Environment ناپایدار
اگر Test Environment مرتباً تغییر کند یا سرویسهای موردنیاز در دسترس نباشند، تشخیص اینکه Test واقعاً Fail شده یا Environment مشکل داشته دشوار میشود.
به همین دلیل Environment باید تا حد امکان قابل اعتماد، کنترلشده و قابل تکرار باشد.
۱۲. نداشتن اولویتبندی
قرار نیست همه بخشهای سیستم دقیقاً به یک اندازه مهم باشند.
مثلاً در یک سیستم بانکی، Payment و Transaction احتمالاً Risk بسیار بالاتری نسبت به یک صفحه Informational دارند.
بنابراین System Testing باید بر اساس مواردی مانند Business Impact + Risk + Criticality + Change Impact اولویتبندی شود.
جمعبندی اشتباهات رایج
بخش بزرگی از مشکلات System Testing زمانی ایجاد میشوند که تیم یکی از این دو رویکرد افراطی را انتخاب کند:
«همه چیز را تست کنیم.»
یا:
«فقط چند مسیر اصلی را تست کنیم.»
رویکرد مناسب بین این دو قرار دارد:
System Testing باید بر اساس Requirements، Risk و Business Value طراحی شود و ترکیبی مناسب از Functional، Non-Functional، Manual و Automated Testing را در بر بگیرد.
۲۲. System Testing در یک پروژه واقعی؛ مثال کامل
برای اینکه مفهوم System Testing کاملاً عملی شود، فرض کنیم قرار است یک فروشگاه اینترنتی را قبل از Release بررسی کنیم.
این سیستم شامل بخشهای مختلفی مانند Login، Product Catalog، Shopping Cart، Order Management، Payment و Notification است.
در این مثال، هدف ما بررسی یک Business Flow واقعی از ابتدا تا انتها است.
مرحله ۱: بررسی Requirement
فرض کنیم Requirement سیستم این است:
کاربر باید بتواند یک محصول موجود را انتخاب کند، آن را خریداری کند و پس از پرداخت موفق، سفارش ثبتشده خود را مشاهده کند.
از این Requirement میتوان چند بخش قابل تست استخراج کرد:
- کاربر باید بتواند وارد حساب خود شود.
- محصول موجود باید قابل خرید باشد.
- محصول باید به Cart اضافه شود.
- مبلغ سفارش باید صحیح محاسبه شود.
- Payment باید انجام شود.
- Order باید ایجاد شود.
- وضعیت سفارش باید صحیح باشد.
- کاربر باید بتواند Order را مشاهده کند.
مرحله ۲: طراحی Test Scenario
بر اساس Requirement، یک سناریوی اصلی تعریف میکنیم:
ثبت موفق سفارش توسط کاربر
جریان کلی:
Login → Search Product → Product Details → Add to Cart → Checkout → Payment → Order → Order History
مرحله ۳: آمادهسازی Test Environment و Test Data
قبل از اجرای تست باید شرایط لازم آماده باشند.
Test User
- Account فعال
- اطلاعات کامل کاربر
- آدرس معتبر
Product
- Product فعال
- Stock کافی
- Price مشخص
Payment
- Test/Sandbox Payment Gateway
- اطلاعات مناسب برای پرداخت موفق
مرحله ۴: اجرای System Test
حالا تستر سناریو را اجرا میکند.
Step 1: Login
Expected Result: کاربر با موفقیت وارد حساب شود.
Step 2: Search Product
Expected Result: محصول موردنظر نمایش داده شود.
Step 3: Add to Cart
Expected Result: محصول با تعداد و قیمت صحیح به Cart اضافه شود.
Step 4: Checkout
Expected Result: اطلاعات سفارش و مبلغ نهایی صحیح باشد.
Step 5: Payment
Expected Result: پرداخت با موفقیت انجام شود.
Step 6: Order Creation
Expected Result: Order ایجاد و شماره سفارش تولید شود.
Step 7: Order History
Expected Result: سفارش ایجادشده در حساب کاربر نمایش داده شود.
اگر تمام مراحل مطابق Expected Result باشند، این System Test موفق خواهد بود.
مرحله ۵: تست سناریوی منفی
حالا همان سیستم را با یک شرایط ناموفق بررسی میکنیم.
فرض کنید Payment Failed شود.
Login → Product → Cart → Checkout → Payment Failed
Expected Result:
- Order نباید بهعنوان سفارش موفق ایجاد شود.
- وضعیت پرداخت باید صحیح ثبت شود.
- پیام مناسب به کاربر نمایش داده شود.
- موجودی محصول نباید بدون دلیل کاهش پیدا کند.
- کاربر باید بتواند دوباره فرآیند پرداخت را انجام دهد، اگر Requirement چنین امکانی را تعریف کرده باشد.
این سناریو نشان میدهد که System Testing فقط بررسی مسیر موفق نیست.
مرحله ۶: ثبت Defect
فرض کنیم در هنگام تست متوجه شویم:
Payment با موفقیت انجام میشود، اما Order در سیستم ایجاد نمیشود.
تستر باید یک Defect ثبت کند.
Title: Order is not created after successful payment
Steps:
- Login
- Select Product
- Add to Cart
- Checkout
- Complete Payment
Expected Result: پس از پرداخت موفق، Order ایجاد شود.
Actual Result: Payment موفق است اما Order ایجاد نمیشود.
این Defect میتواند نشاندهنده یک مشکل در ارتباط یا منطق بین Payment و Order باشد.
مرحله ۷: Retesting
پس از اینکه Developer مشکل را برطرف کرد، تستر همان Scenario را دوباره اجرا میکند.
اگر:
Payment Success → Order Created
اکنون درست انجام شود، Defect میتواند به وضعیت مناسب تغییر کند.
مرحله ۸: Regression Testing
اما کار تمام نشده است.
تغییر انجامشده در Payment یا Order ممکن است بخشهای دیگر را تحت تأثیر قرار داده باشد.
بنابراین Test Caseهای مرتبط نیز دوباره اجرا میشوند.
- Payment Success
- Payment Failure
- Order Creation
- Order Status
- Inventory Update
- Notification
- Order History
- Refund
هدف این است که مطمئن شویم Fix جدید مشکل دیگری در سیستم ایجاد نکرده است.
مرحله ۹: بررسی نتیجه نهایی
در پایان، تستر باید وضعیت کلی تست را مشخص کند.
| مورد | نتیجه |
|---|---|
| Login | Pass |
| Product Search | Pass |
| Cart | Pass |
| Checkout | Pass |
| Payment | Pass |
| Order Creation | Pass |
| Notification | Pass |
| Order History | Pass |
| Regression | Pass |
در صورت وجود Defectهای باز، باید Risk و Impact آنها نیز در تصمیم Release در نظر گرفته شود.
این مثال چه چیزی را درباره System Testing نشان میدهد؟
نکته اصلی این مثال این است که تستر فقط نمیپرسد:
«آیا Payment درست کار میکند؟»
بلکه میپرسد:
«آیا کل فرآیند خرید، از ورود کاربر تا ثبت و مشاهده سفارش، مطابق Requirements کار میکند؟»
و این دقیقاً همان چیزی است که System Testing را از تست یک Component یا Integration Point متمایز میکند.
در یک پروژه واقعی نیز System Testing میتواند بسیار گستردهتر باشد و بر اساس Scope پروژه، علاوه بر این Business Flow، سناریوهای دیگری مانند Compatibility، Performance، Security، Error Handling و Recovery را نیز پوشش دهد.
منابع
- ISTQB Certified Tester Foundation Level Syllabus v4.0.1 — International Software Testing Qualifications Board (ISTQB)
- ISTQB – International Software Testing Qualifications Board — منابع و استانداردهای رسمی تست نرمافزار
- ISTQB Testing Body of Knowledge (TBOK) — مرجع اصطلاحات و دانش تست نرمافزار
- ISTQB Standard Glossary of Terms Used in Software Testing — واژهنامه استاندارد اصطلاحات تست نرمافزار
سوالات متداول درباره System Testing
System Testing چیست؟
System Testing یا تست سیستم یکی از سطوح تست نرمافزار است که در آن سیستم یکپارچه و کامل در برابر Requirements و رفتار مورد انتظار بررسی میشود. هدف این است که مشخص شود کل سیستم، در شرایط تعریفشده، همان چیزی را انجام میدهد که باید انجام دهد.
تفاوت System Testing و Integration Testing چیست؟
در Integration Testing تمرکز اصلی روی ارتباط و تعامل بین اجزای سیستم است؛ اما در System Testing کل سیستم یکپارچه در برابر Requirements ارزیابی میشود.
بهصورت ساده:
Integration Testing: آیا اجزا درست با هم کار میکنند؟
System Testing: آیا کل سیستم درست کار میکند؟
تفاوت System Testing و End-to-End Testing چیست؟
System Testing یک Test Level است، در حالی که End-to-End Testing بیشتر به بررسی یک جریان کامل از ابتدا تا انتها اشاره دارد. این دو میتوانند با یکدیگر همپوشانی داشته باشند؛ برای مثال، یک Business Flow کامل میتواند هم یک System Test و هم یک E2E Test باشد.
تفاوت System Testing و Acceptance Testing چیست؟
System Testing بررسی میکند که سیستم مطابق Requirements عمل میکند؛ اما Acceptance Testing بیشتر بر پذیرش محصول توسط Customer، Business یا User تمرکز دارد.
بنابراین ممکن است یک سیستم از نظر System Testing موفق باشد، اما هنوز نیاز به Acceptance Testing داشته باشد.
آیا System Testing دستی است یا خودکار؟
هر دو. System Testing میتواند بهصورت Manual یا Automated انجام شود.
سناریوهای پایدار و تکرارشونده معمولاً گزینههای خوبی برای Automation هستند، در حالی که Exploratory Testing و بسیاری از بررسیهای نیازمند قضاوت انسانی همچنان میتوانند بهصورت Manual انجام شوند.
آیا System Testing شامل Functional و Non-Functional Testing میشود؟
میتواند شامل هر دو باشد. System Testing یک Test Level است و بر اساس Requirements و Scope پروژه میتواند جنبههایی از Functional و Non-Functional Testing را پوشش دهد.
System Testing چه زمانی انجام میشود؟
در یک مدل سنتی، System Testing معمولاً پس از Integration و آمادهشدن یک Build قابل تست انجام میشود. اما در Agile و Continuous Testing، System Testing میتواند بهصورت تکرارشونده در طول توسعه محصول انجام شود.
آیا System Testing جایگزین Unit و Integration Testing میشود؟
خیر. هر Test Level هدف متفاوتی دارد. Unit Testing برای بررسی واحدهای کوچک، Integration Testing برای بررسی تعامل اجزا و System Testing برای ارزیابی سیستم یکپارچه استفاده میشود.
موفقیت یک سطح به معنی بینیازی از سطوح دیگر نیست.
چه کسی System Testing را انجام میدهد؟
در بسیاری از پروژهها Testers یا QA Engineers مسئول اصلی System Testing هستند، اما بسته به ساختار تیم ممکن است Developers، Automation Engineers، Security Testers و سایر اعضای تیم نیز در بخشهایی از آن مشارکت کنند.
آیا System Testing فقط قبل از Release انجام میشود؟
خیر. ممکن است قبل از Release یک مجموعه گسترده از System Testها اجرا شود، اما در روشهایی مانند Agile، تست سیستم میتواند در طول Sprintها و پس از تغییرات مختلف نیز انجام شود.
آیا System Testing همان Testing کل نرمافزار است؟
System Testing به بررسی سیستم یکپارچه میپردازد، اما به معنی تست کردن همهچیز با هر روش ممکن نیست. Scope تست باید بر اساس Requirements، Risk، Business Impact و اهداف پروژه تعیین شود.
آیا System Testing میتواند همه Bugها را پیدا کند؟
خیر. هیچ Test Level یا Test Typeای نمیتواند تضمین کند که نرمافزار کاملاً بدون Bug است.
System Testing فقط نشان میدهد که سیستم در سناریوها، شرایط و محدودهای که تست شدهاند چه رفتاری داشته است.
آیا System Testing برای Microservices هم کاربرد دارد؟
بله. حتی در معماریهای Microservices نیز میتوان رفتار کل سیستم را در سطح System Testing بررسی کرد.
برای مثال، یک Business Flow ممکن است چند Service مختلف را درگیر کند و System Testing میتواند رفتار این جریان را در سطح محصول بررسی کند. برای بررسی دقیق ارتباط بین Serviceها نیز Integration Testing و Contract Testing اهمیت دارند.
آیا System Testing برای Web و Mobile متفاوت است؟
اصول کلی یکسان است، اما Scope و شرایط تست بر اساس نوع محصول تغییر میکند.
برای Web Application ممکن است Browser و OSهای مختلف مهم باشند، در حالی که در Mobile Application مواردی مانند Device، OS Version، Screen Size، Network Condition و Hardware نیز اهمیت بیشتری پیدا میکنند.
