انواع تست نرم افزار چیست؟ راهنمای جامع دسته‌بندی‌های Software Testing

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

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

برای مثال، Functional Testing و Non-functional Testing درباره جنبه‌ای هستند که می‌خواهیم در نرم‌افزار بررسی کنیم؛ در حالی که Component Testing و System Testing به سطحی از نرم‌افزار مربوط می‌شوند که تست در آن انجام می‌شود. از طرف دیگر، Black-box و White-box به رویکرد و تکنیک طراحی تست مربوط‌اند و Manual و Automated شیوه اجرای تست را توصیف می‌کنند.

در ISTQB نیز دسته‌بندی تست‌ها یک فهرست ساده و خطی نیست. برای درک درست آن باید چند مفهوم را در کنار یکدیگر دید؛ از Test Types و Test Levels گرفته تا Test Techniques و شیوه‌هایی مانند تست استاتیک و داینامیک.

در این مقاله ابتدا یک نقشه کلی از این دسته‌بندی‌ها ارائه می‌کنیم و سپس مهم‌ترین Test Types شامل Functional، Non-functional، Structural و Change-related Testing را بررسی می‌کنیم. در ادامه نیز با سطوح تست و تکنیک‌های طراحی تست آشنا می‌شویم تا مشخص شود هر کدام دقیقاً چه جایگاهی در فرایند تست نرم افزار دارند.

هدف این مقاله حفظ کردن یک فهرست طولانی از نام تست‌ها نیست؛ بلکه کمک به ایجاد یک تصویر ذهنی منظم از انواع تست نرم افزار است تا وقتی با اصطلاحاتی مانند Regression، Unit، Performance یا Black-box مواجه می‌شوید، بدانید هر کدام به کدام بُعد از تست مربوط هستند و چه تفاوتی با یکدیگر دارند.

چرا دسته‌بندی انواع تست نرم افزار متفاوت است؟

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

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

• نوع سوخت
• اندازه خودرو
• کاربری
• قیمت
• قدرت موتور

دسته‌بندی‌های مختلف، لزوماً با یکدیگر تضاد ندارند؛ بلکه هر کدام یک ویژگی متفاوت را بررسی می‌کنند.

در تست نرم‌افزار نیز دقیقاً همین اتفاق رخ می‌دهد.

برای مثال:

• System Testing مشخص می‌کند چه سطحی از نرم‌افزار تست شده است.
• Functional Testing هدف تست را مشخص می‌کند.
• Regression Testing نشان می‌دهد تست مربوط به تغییرات سیستم است.
• Automated Testing روش اجرای تست را مشخص می‌کند.
• Black-box Testing میزان آگاهی تستر از ساختار داخلی سیستم را توضیح می‌دهد.

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

دسته‌بندی‌های اصلی تست نرم افزار

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

• بر اساس نحوه اجرای نرم‌افزار: Static Testing و Dynamic Testing
• بر اساس سطح تست: Testing Levels
• بر اساس هدف تست: Functional و Non-functional Testing
• بر اساس تغییرات: Change-related Testing
• بر اساس روش اجرا: Manual و Automated Testing
• بر اساس میزان آگاهی از ساختار داخلی: Black-box، Gray-box و White-box Testing
• بر اساس روش طراحی تست کیس: Test Design Techniques

📚 در ادامه مقاله هر دسته‌بندی را جداگانه بررسی می‌کنیم و با مثال‌های واقعی از پروژه BlueBank جایگاه هر نوع تست را مشخص خواهیم کرد.

یک نقشه ساده برای درک انواع تست در ISTQB

اگر بخواهیم مفاهیم تست نرم‌افزار را بر اساس چارچوب ISTQB منظم کنیم، بهتر است سه مفهوم را از یکدیگر جدا کنیم:

• Test Types (انواع تست): مشخص می‌کنند چه جنبه‌ای از نرم‌افزار یا چه نوع تغییری را بررسی می‌کنیم.
• Test Levels (سطوح تست): مشخص می‌کنند تست در چه سطحی از نرم‌افزار انجام می‌شود.
• Test Techniques (تکنیک‌های تست): مشخص می‌کنند تست‌ها را با چه روشی طراحی می‌کنیم.

در چارچوب ISTQB، چهار Test Type اصلی عبارت‌اند از:

1. Functional Testing: بررسی اینکه نرم‌افزار چه کاری انجام می‌دهد و آیا عملکرد مورد انتظار را ارائه می‌کند یا خیر.
2. Non-functional Testing: بررسی ویژگی‌های کیفی و اینکه سیستم چگونه وظایف خود را انجام می‌دهد؛ مانند Performance و Usability.
3. Structural Testing: بررسی ساختار داخلی نرم‌افزار، مانند ساختار کد و مسیرهای اجرای آن.
4. Change-related Testing: تست‌هایی که در ارتباط با تغییرات نرم‌افزار انجام می‌شوند؛ مانند Confirmation Testing و Regression Testing.

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

اما این تنها یکی از ابعاد تست نرم‌افزار است. برای مثال، یک تست Functional می‌تواند در سطح Component، Integration یا System انجام شود و با استفاده از یک تکنیک مشخص برای طراحی Test Case طراحی شود.

سه مفهوم را با هم اشتباه نگیریم

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

• Test Type: می‌تواند Functional باشد؛ چون می‌خواهیم بررسی کنیم انتقال وجه درست انجام می‌شود یا خیر.
• Test Level: می‌تواند System Testing باشد؛ چون کل جریان انتقال وجه را بررسی می‌کنیم.
• Test Technique: می‌تواند یک تکنیک Black-box باشد؛ چون برای طراحی تست بر رفتار و نیازمندی‌های سیستم تمرکز داریم، نه ساختار داخلی کد.

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

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

تست بر اساس اجرای نرم‌افزار(Static و Dynamic)

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

آیا برای انجام تست، نرم‌افزار باید اجرا شود؟

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

• Static Testing
• Dynamic Testing

Static Testing (تست ایستا)

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

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

سؤال اصلی در این دسته‌بندی این است:

🔍 آیا می‌توانیم قبل از اجرای نرم‌افزار، مشکلات موجود را پیدا کنیم؟

روش‌های رایج Static Testing

• Review: بررسی مستندات، نیازمندی‌ها، طراحی سیستم یا کد توسط افراد تیم.
• Static Analysis: بررسی خودکار کد با استفاده از ابزارها برای پیدا کردن مشکلات احتمالی.
• Walkthrough: ارائه و بررسی یک بخش از محصول یا مستندات توسط نویسنده آن.
• Inspection: یک فرآیند رسمی و ساختاریافته برای پیدا کردن نقص‌ها.

مثال از پروژه BlueBank

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

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

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

این بررسی‌ها بدون اجرای سیستم انجام می‌شوند و نمونه‌ای از Static Testing هستند.

💡 Static Testing کمک می‌کند مشکلات زودتر پیدا شوند؛ زمانی که اصلاح آن‌ها هزینه کمتری دارد.

Dynamic Testing (تست پویا)

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

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

⚙️ سؤال اصلی Dynamic Testing: «آیا نرم‌افزار هنگام اجرا همان رفتاری را دارد که انتظار داریم؟»

نمونه‌هایی از Dynamic Testing

• اجرای Test Caseهای دستی
• اجرای تست‌های خودکار با ابزارهایی مانند Playwright یا Selenium
• تست APIها
• تست رابط کاربری
• تست عملکرد و امنیت

مثال از پروژه BlueBank

در Dynamic Testing، تستر وارد سامانه بانکی می‌شود، اطلاعات انتقال وجه را وارد می‌کند و بررسی می‌کند:

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

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

مقایسه Static و Dynamic Testing

ویژگی	Static Testing	Dynamic Testing
اجرای نرم‌افزار	نیازی به اجرا ندارد	نیاز به اجرای نرم‌افزار دارد
زمان انجام	معمولاً در مراحل اولیه توسعه	پس از آماده شدن قابلیت قابل اجرا
تمرکز	مستندات، طراحی و کد	رفتار واقعی سیستم
مثال	Code Review	Functional Testing

آیا Static Testing جایگزین Dynamic Testing است؟

خیر. این دو روش مکمل یکدیگر هستند.

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

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

📝 QA Note: در استاندارد ISTQB، Static Testing و Dynamic Testing دو رویکرد کلی برای انجام تست هستند. این دسته‌بندی درباره «اجرا شدن یا نشدن نرم‌افزار» صحبت می‌کند، نه درباره سطح یا هدف تست.

---

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

سطوح تست Test Levels چیست؟

Test Levels مشخص می‌کنند تست در چه سطحی از نرم‌افزار انجام می‌شود.

ISTQB چهار سطح اصلی تست را معرفی می‌کند:

Component → Integration → System → Acceptance

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

انواع تست بر اساس هدف Testing Types

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

سؤال اصلی در این دسته‌بندی این است:

🎯 هدف ما از انجام این تست چیست؟ چه چیزی را می‌خواهیم بررسی کنیم؟

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

• Functional Testing (تست عملکردی)
• Non-functional Testing (تست غیرعملکردی)

Functional Testing (تست عملکردی)

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

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

💡 Functional Testing می‌پرسد: «آیا سیستم کار درست را انجام می‌دهد؟»

نمونه‌هایی از Functional Testing

• Unit / Component Testing: بررسی عملکرد یک بخش کوچک از نرم‌افزار.
• Integration Testing: بررسی درست کار کردن ارتباط بین بخش‌ها.
• System Testing: بررسی عملکرد کل سیستم.
• Acceptance Testing: بررسی اینکه محصول نیازهای کسب‌وکار را برآورده می‌کند.
• Smoke Testing: بررسی سریع قابلیت‌های اصلی یک Build جدید.
• Sanity Testing: بررسی محدود و سریع یک تغییر یا اصلاح خاص.
• Regression Testing: اطمینان از اینکه تغییرات جدید باعث خراب شدن قابلیت‌های قبلی نشده‌اند.

مثال از پروژه BlueBank

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

در Functional Testing بررسی می‌کنیم:

• آیا کاربر می‌تواند مبلغ انتقال را وارد کند؟
• آیا سیستم موجودی حساب را بررسی می‌کند؟
• آیا مبلغ صحیح از حساب کم می‌شود؟
• آیا حساب مقصد مبلغ را دریافت می‌کند؟
• آیا رسید موفقیت نمایش داده می‌شود؟

تمام این موارد مربوط به رفتار مورد انتظار سیستم هستند.

Non-functional Testing (تست غیرعملکردی)

Non-functional Testing بررسی می‌کند نرم‌افزار چگونه وظایف خود را انجام می‌دهد.

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

⚡ Non-functional Testing می‌پرسد: «سیستم چقدر خوب کار می‌کند؟»

مهم‌ترین انواع Non-functional Testing

• Performance Testing: بررسی سرعت، پاسخگویی و رفتار سیستم تحت بارهای مختلف.
• Load Testing: بررسی عملکرد سیستم در حجم مشخصی از کاربران یا درخواست‌ها.
• Stress Testing: بررسی رفتار سیستم در شرایط بیشتر از ظرفیت معمول.
• Security Testing: بررسی آسیب‌پذیری‌ها و امنیت سیستم.
• Usability Testing: بررسی راحتی استفاده کاربران از نرم‌افزار.
• Compatibility Testing: بررسی عملکرد نرم‌افزار در محیط‌ها، مرورگرها و دستگاه‌های مختلف.
• Reliability Testing: بررسی پایداری و قابلیت اعتماد سیستم.

مثال از پروژه BlueBank

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

برای مثال:

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

این موارد مربوط به کیفیت و ویژگی‌های سیستم هستند، نه عملکرد اصلی آن.

مقایسه Functional و Non-functional Testing

ویژگی	Functional Testing	Non-functional Testing
تمرکز	چه کاری انجام می‌دهد؟	چگونه انجام می‌دهد؟
بررسی	رفتار و قابلیت‌ها	کیفیت و ویژگی‌های سیستم
مثال	ثبت سفارش موفق	زمان پاسخ صفحه سفارش
نمونه تست	Login Testing	Performance Testing

آیا Functional مهم‌تر از Non-functional است؟

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

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

📝 QA Note: در ISTQB، Functional Testing و Non-functional Testing به‌عنوان دسته‌بندی بر اساس هدف تست شناخته می‌شوند. این دسته‌بندی با Testing Levels تفاوت دارد.

---

جمع‌بندی: Functional Testing بررسی می‌کند که نرم‌افزار وظایف مورد انتظار را انجام می‌دهد یا خیر؛ در حالی که Non-functional Testing کیفیت انجام این وظایف را ارزیابی می‌کند.

Structural Testing چیست؟

Structural Testing یا تست ساختاری یکی از چهار Test Type در چارچوب ISTQB است که به‌جای تمرکز صرف بر رفتار قابل مشاهده سیستم، بر ساختار داخلی نرم‌افزار و نحوه پردازش آن تمرکز می‌کند.

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

به همین دلیل، Structural Testing معمولاً به اطلاعاتی درباره ساختار داخلی سیستم نیاز دارد و با مفاهیمی مانند Statement Coverage و Branch Coverage ارتباط نزدیکی دارد.

Structural Testing چه چیزی را بررسی می‌کند؟

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

بنابراین، در Structural Testing سؤال اصلی این نیست که فقط «آیا سیستم خروجی درست می‌دهد؟»، بلکه می‌توان پرسید:

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

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

نمونه‌هایی از Structural Testing

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

• Statement Coverage: بررسی می‌کند چه میزان از دستورهای قابل اجرای کد توسط تست‌ها اجرا شده‌اند.
• Branch Coverage: بررسی می‌کند شاخه‌های مختلف تصمیم‌گیری، مانند مسیرهای True و False، تا چه اندازه توسط تست‌ها پوشش داده شده‌اند.

برای مثال، اگر یک بخش از کد دارای یک شرط if/else باشد، اجرای فقط یکی از مسیرها به این معنی نیست که هر دو شاخه تست شده‌اند. Structural Testing می‌تواند برای بررسی پوشش این مسیرهای داخلی مورد استفاده قرار گیرد.

Structural Testing در کدام سطح تست انجام می‌شود؟

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

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

بنابراین باید بین این دو مفهوم تفاوت قائل شد: Structural Testing یک Test Type است، در حالی که Component، Integration، System و Acceptance، Test Level هستند. این دو دسته‌بندی پاسخ متفاوتی به سؤال «تست را چگونه دسته‌بندی می‌کنیم؟» می‌دهند.

تست‌های مرتبط با تغییرات Change-related Testing

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

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

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

اما هر تغییر می‌تواند روی بخش‌های دیگر نرم‌افزار اثر بگذارد. به همین دلیل، پس از اعمال تغییرات، تست‌های خاصی انجام می‌شوند که به آن‌ها Change-related Testing گفته می‌شود.

🎯 سؤال اصلی این دسته‌بندی:

«بعد از ایجاد تغییر، چگونه مطمئن شویم مشکل برطرف شده و قابلیت‌های قبلی خراب نشده‌اند؟»

در این دسته‌بندی دو مفهوم مهم وجود دارد:

• Confirmation Testing
• Regression Testing

Confirmation Testing (تست تأییدی)

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

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

🔍 سؤال Confirmation Testing:

«آیا اصلاح انجام‌شده، مشکل موردنظر را حل کرده است؟»

مثال از پروژه BlueBank

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

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

در Confirmation Testing بررسی می‌کنیم:

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

Regression Testing (تست بازگشتی)

Regression Testing برای بررسی این انجام می‌شود که آیا تغییرات جدید باعث ایجاد مشکل در بخش‌های قبلی سیستم شده‌اند یا خیر.

حتی یک تغییر کوچک می‌تواند روی بخش‌های دیگری از نرم‌افزار تأثیر بگذارد.

🔄 سؤال Regression Testing:

«آیا تغییر جدید چیزی را که قبلاً درست کار می‌کرد، خراب کرده است؟»

مثال از پروژه BlueBank

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

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

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

این بررسی‌ها نمونه‌ای از Regression Testing هستند.

تفاوت Confirmation Testing و Regression Testing

ویژگی	Confirmation Testing	Regression Testing
هدف	بررسی رفع یک مشکل مشخص	بررسی اثرات جانبی تغییر
تمرکز	همان بخش دارای خطا	بخش‌های مرتبط یا کل سیستم
زمان اجرا	پس از رفع باگ	پس از تغییرات مختلف
سؤال اصلی	آیا مشکل حل شد؟	آیا چیز دیگری خراب شد؟

آیا Regression Testing فقط بعد از رفع باگ انجام می‌شود؟

خیر. Regression Testing فقط مربوط به رفع باگ نیست.

هر تغییری که احتمال تأثیر روی بخش‌های دیگر سیستم داشته باشد، می‌تواند نیازمند Regression Testing باشد.

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

ارتباط Regression Testing با Automation

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

برای مثال، در پروژه BlueBank می‌توان سناریوهای مهم مانند ورود، انتقال وجه و پرداخت قبض را به‌صورت خودکار اجرا کرد تا پس از هر تغییر، سریع بررسی شوند.

📝 QA Note: در ISTQB، Confirmation Testing و Regression Testing به‌عنوان تست‌های مرتبط با تغییرات معرفی می‌شوند. این دسته‌بندی با Functional Testing یا Testing Level متفاوت است.

---

جمع‌بندی: Confirmation Testing بررسی می‌کند که آیا یک مشکل مشخص رفع شده است، در حالی که Regression Testing اطمینان می‌دهد تغییرات جدید باعث ایجاد مشکل در قابلیت‌های قبلی نشده‌اند.

Manual Testing و Automated Testing (بر اساس روش اجرا)

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

در این دسته‌بندی، سؤال اصلی این است:

⚙️ تست توسط انسان اجرا می‌شود یا توسط ابزار و اسکریپت؟

بر اساس پاسخ این سؤال، تست‌ها به دو گروه تقسیم می‌شوند:

• Manual Testing (تست دستی)
• Automated Testing (تست خودکار)

Manual Testing (تست دستی)

Manual Testing یعنی اجرای سناریوهای تست توسط تستر، بدون استفاده از اسکریپت خودکار.

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

👤 در Manual Testing، انسان نقش اصلی را در مشاهده، تحلیل و تصمیم‌گیری دارد.

مثال از پروژه BlueBank

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

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

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

مزایای Manual Testing

• مناسب برای تست‌های اکتشافی (Exploratory Testing)
• امکان مشاهده تجربه واقعی کاربر
• انعطاف‌پذیری بالا در سناریوهای غیرقابل پیش‌بینی
• مناسب برای تست‌های کوتاه‌مدت یا یک‌بار مصرف

محدودیت‌های Manual Testing

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

Automated Testing (تست خودکار)

Automated Testing یعنی اجرای Test Caseها با استفاده از ابزارها و اسکریپت‌های خودکار.

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

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

مثال از پروژه BlueBank

تیم QA تصمیم می‌گیرد سناریوی ورود کاربران را خودکار کند.

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

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

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

نمونه ابزارهای Automated Testing

• Playwright: برای تست خودکار وب و سناریوهای End-to-End
• Selenium: یکی از ابزارهای قدیمی و پرکاربرد تست مرورگر
• Cypress: برای تست‌های Front-end و وب
• JUnit / PyTest: برای تست‌های خودکار در سطح کد

مزایای Automated Testing

• سرعت بالاتر در اجرای تست‌های تکراری
• مناسب برای Regression Testing
• امکان اجرای تست‌های زیاد در مدت کوتاه
• قابل استفاده در CI/CD Pipeline

محدودیت‌های Automated Testing

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

آیا Automation جایگزین Manual Testing می‌شود؟

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

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

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

مقایسه Manual و Automated Testing

ویژگی	Manual Testing	Automated Testing
اجرا	توسط انسان	توسط ابزار و اسکریپت
سرعت	کندتر در تست‌های تکراری	سریع‌تر
هزینه اولیه	کمتر	بیشتر
مناسب برای	Exploratory و تست‌های جدید	Regression و تست‌های تکراری

📝 QA Note: Manual و Automated Testing درباره «روش اجرا» صحبت می‌کنند، نه درباره هدف یا سطح تست. برای مثال، یک System Functional Regression Test می‌تواند هم دستی و هم خودکار اجرا شود.

---

جمع‌بندی: Manual Testing و Automated Testing دو روش متفاوت برای اجرای تست هستند. انتخاب بین آن‌ها به نوع تست، زمان، هزینه و نیازهای پروژه بستگی دارد و در پروژه‌های حرفه‌ای معمولاً ترکیبی از هر دو استفاده می‌شود.

Black-box، Gray-box و White-box Testing (بر اساس میزان دسترسی به ساختار داخلی)

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

سؤال اصلی در این دسته‌بندی این است:

🔍 تستر هنگام طراحی و اجرای تست، چقدر از کد، معماری و منطق داخلی سیستم اطلاع دارد؟

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

• Black-box Testing
• White-box Testing
• Gray-box Testing

Black-box Testing (تست جعبه سیاه)

در Black-box Testing تستر بدون نیاز به دانستن جزئیات داخلی سیستم، رفتار نرم‌افزار را بررسی می‌کند.

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

⬛ در Black-box Testing تستر می‌پرسد: «اگر این ورودی را وارد کنم، آیا خروجی مورد انتظار را دریافت می‌کنم؟»

مثال از پروژه BlueBank

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

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

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

این یک نمونه از Black-box Testing است.

مزایای Black-box Testing

• نزدیک به دیدگاه کاربر نهایی است.
• نیازی به دانش عمیق برنامه‌نویسی ندارد.
• برای تست‌های Functional و Acceptance بسیار کاربردی است.
• می‌تواند مشکلات مربوط به رفتار سیستم را پیدا کند.

White-box Testing (تست جعبه سفید)

در White-box Testing تستر یا توسعه‌دهنده به ساختار داخلی سیستم، کد و منطق پیاده‌سازی دسترسی دارد.

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

⬜ در White-box Testing سؤال اصلی این است: «آیا منطق داخلی کد درست پیاده‌سازی شده است؟»

مثال از پروژه BlueBank

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

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

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

نمونه تکنیک‌های White-box Testing

• Statement Coverage
• Branch Coverage
• Condition Coverage
• Path Testing

Gray-box Testing (تست جعبه خاکستری)

Gray-box Testing ترکیبی از Black-box و White-box Testing است.

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

⚫ در Gray-box Testing تستر بخشی از «درون سیستم» را می‌داند، اما همچنان رفتار کلی سیستم را بررسی می‌کند.

مثال از پروژه BlueBank

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

اما به جای بررسی خط‌به‌خط کد، APIها را آزمایش می‌کند و بررسی می‌کند:

• آیا درخواست‌ها درست پردازش می‌شوند؟
• آیا مجوزهای دسترسی درست بررسی می‌شوند؟
• آیا داده صحیح بین سرویس‌ها منتقل می‌شود؟

این نوع تست در API Testing و تست سیستم‌های پیچیده بسیار رایج است.

مقایسه Black-box، Gray-box و White-box

ویژگی	Black-box	Gray-box	White-box
دسترسی به کد	ندارد	محدود	دارد
تمرکز	رفتار سیستم	رفتار + بخشی از ساختار داخلی	منطق داخلی کد
معمولاً توسط	تستر QA	QA فنی یا تستر API	توسعه‌دهنده یا SDET
مثال	UI Testing	API Testing	Unit Testing

آیا Black-box یعنی تستر هیچ اطلاعاتی ندارد؟

خیر. Black-box به این معنی نیست که تستر هیچ دانشی از سیستم ندارد.

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

📝 QA Note: تفاوت اصلی این دسته‌بندی بر اساس «میزان دسترسی و آگاهی از ساختار داخلی سیستم» است، نه بر اساس مهارت یا دانش تستر.

---

نکته: توجه کنید که در CTFL، تکنیک‌های طراحی تست در سه گروه Black-box، White-box و Experience-based معرفی می‌شوند. Gray-box در این دسته‌بندی سه‌گانه ISTQB به‌عنوان یک گروه مستقل قرار نمی‌گیرد و بیشتر یک اصطلاح رایج در صنعت برای حالتی بین Black-box و White-box است.

بنابراین سه مورد Black-box / Gray-box / White-box یک نگاه رایج به میزان دسترسی یا شناخت ساختار داخلی است و سه مورد Black-box / White-box / Experience-based تکنیک‌های تست در istqb هستند.

Test Techniques چیست؟

Test Techniques مشخص می‌کنند تستر چگونه Test Caseهای خود را طراحی می‌کند.

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

• Black-box Testing Techniques
• White-box Testing Techniques
• Experience-based Testing Techniques

تکنیک‌هایی مانند Boundary Value Analysis، Branch Testing و Error Guessing در این حوزه قرار می‌گیرند.

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

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

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

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

🎯 یک تست معمولاً فقط «یک نوع» نیست؛ بلکه ویژگی‌های مختلفی دارد که از معیارهای مختلف قابل بررسی هستند.

مثال واقعی از پروژه BlueBank

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

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

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

معیار دسته‌بندی	نوع تست	دلیل
سطح تست	System Testing	کل فرآیند انتقال وجه بررسی می‌شود.
هدف تست	Functional Testing	درستی عملکرد انتقال وجه بررسی می‌شود.
روش اجرا	Manual Testing	اگر تستر آن را دستی اجرا کند.
روش طراحی	Black-box Testing	بدون بررسی کد داخلی سیستم.
تغییرات	Regression Testing	اگر پس از تغییر سیستم اجرا شود.

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

ارتباط بین دسته‌بندی‌های مختلف تست

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

• Testing Level: مشخص می‌کند چه بخشی از سیستم تست می‌شود.
• Testing Type: مشخص می‌کند هدف تست چیست.
• Test Execution Method: مشخص می‌کند تست چگونه اجرا می‌شود.
• Test Approach: مشخص می‌کند تستر چه میزان اطلاعاتی از ساختار داخلی دارد.
• Test Design Technique: مشخص می‌کند Test Case چگونه طراحی شده است.

این لایه‌ها جایگزین یکدیگر نیستند؛ بلکه مکمل هم هستند.

یک مثال برای درک بهتر ترکیب دسته‌بندی‌ها

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

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

• Functional Testing: بررسی می‌کند ورود موفق انجام می‌شود یا خیر.
• System Testing: چون کل جریان ورود کاربر بررسی می‌شود.
• Black-box Testing: چون تستر فقط رفتار سیستم را مشاهده می‌کند.
• Manual Testing: اگر تستر مراحل را دستی انجام دهد.
• Regression Testing: اگر بعد از تغییر سیستم اجرا شود.

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

اشتباه رایج: مقایسه اشتباه دسته‌بندی‌ها

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

برای مثال:

• مقایسه Smoke Testing با Performance Testing
• مقایسه Unit Testing با Regression Testing
• مقایسه Manual Testing با Functional Testing

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

سؤال	دسته‌بندی مرتبط
چه بخشی را تست می‌کنیم؟	Testing Levels
چه چیزی را بررسی می‌کنیم؟	Testing Types
چگونه اجرا می‌کنیم؟	Manual / Automated
چقدر از داخل سیستم می‌دانیم؟	Black-box / White-box
چگونه تست طراحی کنیم؟	Test Design Techniques

نقش ISTQB در دسته‌بندی تست‌ها

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

در ISTQB مفاهیمی مانند:

• Testing Levels
• Testing Types
• Test Techniques
• Test Activities

هر کدام جایگاه مشخصی دارند.

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

📝 QA Note: یک تستر حرفه‌ای نمی‌پرسد «این تست دقیقاً چه نوعی است؟»؛ بلکه می‌پرسد «بر اساس کدام معیار می‌خواهیم آن را دسته‌بندی کنیم؟»

---

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

نقشه جامع انواع تست نرم افزار (Software Testing Cheat Sheet)

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

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

۱. دسته‌بندی بر اساس اجرای نرم‌افزار

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

• Static Testing: بررسی نرم‌افزار بدون اجرای آن.
• Dynamic Testing: بررسی رفتار نرم‌افزار هنگام اجرا.

مثال:

• Code Review → Static Testing
• اجرای Test Case ورود کاربر → Dynamic Testing

---

۲. دسته‌بندی بر اساس سطح تست (Testing Levels)

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

• Component Testing: تست یک بخش کوچک یا واحد مستقل.
• Integration Testing: تست ارتباط بین بخش‌ها.
• System Testing: تست کل سیستم.
• Acceptance Testing: بررسی آمادگی محصول برای استفاده نهایی.

مثال در BlueBank:

• تست تابع محاسبه کارمزد → Component Testing
• ارتباط سرویس انتقال وجه با حساب → Integration Testing
• فرآیند کامل انتقال وجه → System Testing
• تأیید سیستم توسط بانک → Acceptance Testing

---

۳. دسته‌بندی بر اساس هدف تست (Testing Types)

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

• Functional Testing: بررسی درست انجام شدن قابلیت‌ها.
• Non-functional Testing: بررسی کیفیت‌هایی مانند سرعت، امنیت و قابلیت استفاده.

مثال:

• آیا انتقال وجه انجام می‌شود؟ → Functional Testing
• آیا انتقال وجه در زمان مناسب انجام می‌شود؟ → Performance Testing

---

۴. دسته‌بندی بر اساس تغییرات سیستم

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

• Confirmation Testing: بررسی رفع یک مشکل مشخص.
• Regression Testing: بررسی اینکه تغییرات جدید باعث خرابی بخش‌های قبلی نشده‌اند.

مثال:

• بررسی رفع خطای ورود → Confirmation Testing
• بررسی دوباره ورود، پرداخت و انتقال وجه پس از تغییر → Regression Testing

---

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

• Manual Testing: اجرای تست توسط انسان.
• Automated Testing: اجرای تست توسط ابزار و اسکریپت.

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

---

۶. دسته‌بندی بر اساس میزان آگاهی از ساختار داخلی

• Black-box Testing: بدون نیاز به بررسی کد داخلی.
• Gray-box Testing: با اطلاعات محدود از ساختار داخلی.
• White-box Testing: با دسترسی به منطق داخلی و کد.

مثال:

• تست رفتار صفحه ورود → Black-box
• تست API با شناخت معماری سرویس‌ها → Gray-box
• بررسی مسیرهای اجرای کد → White-box

---

جدول نهایی ارتباط دسته‌بندی‌های تست

سؤال اصلی	دسته‌بندی	نمونه
آیا سیستم اجرا می‌شود؟	Static / Dynamic	Code Review / Test Execution
چه سطحی تست می‌شود؟	Testing Levels	Unit، Integration، System
هدف تست چیست؟	Testing Types	Functional، Performance
آیا تغییر ایجاد شده؟	Change-related Testing	Regression
چگونه اجرا می‌شود؟	Manual / Automated	دستی یا اسکریپت
چقدر از داخل سیستم می‌دانیم؟	Black/Gray/White-box	رفتار یا کد داخلی

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

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

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

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

🎯 یک تستر حرفه‌ای به جای حفظ کردن لیست انواع تست، رابطه بین آن‌ها را درک می‌کند.

---

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

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

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

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

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

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

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

برای مثال:

تست فرآیند پرداخت آنلاین در یک اپلیکیشن بانکی

• از نظر هدف → Functional Testing
• از نظر سطح → System Testing
• از نظر اجرا → Manual یا Automated Testing
• از نظر آگاهی از ساختار → Black-box Testing
• پس از تغییر سیستم → Regression Testing

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

اشتباه دوم: مقایسه Unit Testing با Functional Testing

گاهی افراد می‌پرسند:

آیا Unit Testing بهتر است یا Functional Testing؟

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

• Unit Testing: درباره سطح تست صحبت می‌کند.
• Functional Testing: درباره هدف تست صحبت می‌کند.

یک Unit Test می‌تواند Functional باشد، چون ممکن است عملکرد یک تابع خاص را بررسی کند.

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

خودکار بودن یک تست به معنی بهتر بودن آن نیست.

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

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

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

اشتباه چهارم: تصور اینکه تستر Black-box هیچ اطلاعات فنی ندارد

Black-box Testing به معنی نداشتن دانش فنی نیست.

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

🔍 تفاوت Black-box و White-box در میزان استفاده از ساختار داخلی سیستم است، نه در میزان حرفه‌ای بودن تستر.

اشتباه پنجم: قرار دادن Smoke Testing و Performance Testing در یک دسته

در بسیاری از مقالات اینترنتی، Smoke Testing و Performance Testing در کنار هم به عنوان «انواع تست» معرفی می‌شوند.

اما این موضوع می‌تواند باعث سردرگمی شود.

• Smoke Testing: بیشتر درباره بررسی سریع قابلیت‌های اصلی یک Build جدید است.
• Performance Testing: درباره بررسی ویژگی‌های غیرعملکردی مانند سرعت و ظرفیت سیستم است.

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

نکات مهم برای مصاحبه QA

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

مصاحبه‌کننده بیشتر بررسی می‌کند که آیا منطق پشت این دسته‌بندی‌ها را متوجه شده‌اید یا خیر.

سؤال: تفاوت Functional و Non-functional Testing چیست؟

پاسخ مناسب:

Functional Testing بررسی می‌کند سیستم چه کاری انجام می‌دهد، در حالی که Non-functional Testing کیفیت انجام آن کار مانند سرعت، امنیت و قابلیت استفاده را بررسی می‌کند.

سؤال: تفاوت Regression و Confirmation Testing چیست؟

پاسخ مناسب:

Confirmation Testing بررسی می‌کند یک باگ مشخص رفع شده است؛ Regression Testing بررسی می‌کند تغییرات جدید باعث ایجاد مشکل در بخش‌های دیگر نشده‌اند.

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

پاسخ مناسب:

خیر. Automation برای تست‌هایی که تکراری، پایدار و زمان‌بر هستند مناسب است، اما تست‌هایی مانند Exploratory Testing و بسیاری از تست‌های تجربه کاربری همچنان به انسان نیاز دارند.

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

اشتباه	واقعیت
هر تست فقط یک نوع دارد	یک تست می‌تواند چند ویژگی هم‌زمان داشته باشد.
Automation همیشه بهتر است	انتخاب روش اجرا به شرایط پروژه بستگی دارد.
Black-box یعنی تستر غیر فنی است	تفاوت در میزان استفاده از ساختار داخلی است.
Smoke و Performance یک دسته هستند	هر کدام از معیار متفاوتی می‌آیند.

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

---

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

سوالات متداول درباره انواع تست نرم افزار (FAQ)

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

۱. چرا دسته‌بندی انواع تست نرم افزار در منابع مختلف متفاوت است؟

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

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

• Functional Testing
• Non-functional Testing

در حالی که منبع دیگری ممکن است بر اساس سطح تست صحبت کند:

• Unit Testing
• Integration Testing
• System Testing

این تفاوت به معنی وجود تناقض نیست؛ بلکه هر دسته‌بندی به یک سؤال متفاوت پاسخ می‌دهد.

۲. آیا دسته‌بندی ISTQB با دسته‌بندی‌های رایج اینترنت متفاوت است؟

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

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

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

۳. آیا Unit Testing یک نوع تست است یا یک سطح تست؟

در استانداردهای حرفه‌ای مانند ISTQB، Unit Testing بیشتر به عنوان یک Test Level یا سطح تست شناخته می‌شود.

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

برای جلوگیری از سردرگمی بهتر است همیشه بپرسیم:

«نوع تست از چه دیدگاهی تعریف شده است؟»

۴. آیا Smoke Testing یک تست Functional است؟

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

بسته به سناریوی اجرا، Smoke Testing می‌تواند شامل بررسی قابلیت‌های Functional باشد، اما خودش یک دسته‌بندی مستقل با هدف مشخص است.

۵. تفاوت Smoke Testing و Regression Testing چیست؟

Smoke Testing بررسی می‌کند آیا نسخه جدید آن‌قدر پایدار هست که تست‌های عمیق‌تر روی آن انجام شود یا خیر.

Regression Testing بررسی می‌کند تغییرات جدید باعث خراب شدن قابلیت‌های قبلی نشده باشند.

	Smoke Testing	Regression Testing
هدف	بررسی سریع پایداری Build	بررسی اثر تغییرات
دامنه	محدود	معمولاً گسترده‌تر
زمان اجرا	ابتدای فرآیند تست	پس از تغییرات

۶. آیا تست دستی در آینده از بین می‌رود؟

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

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

۷. آیا Performance Testing جزو Functional Testing است؟

خیر. Performance Testing معمولاً زیرمجموعه Non-functional Testing قرار می‌گیرد.

Functional Testing بررسی می‌کند سیستم چه کاری انجام می‌دهد، اما Performance Testing بررسی می‌کند سیستم این کار را با چه سرعت و کیفیتی انجام می‌دهد.

۸. برای شروع یادگیری تست نرم افزار باید همه انواع تست را یاد بگیریم؟

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

• ابتدا مفاهیم پایه QA و فرآیند تست
• Testing Levels و Testing Types
• طراحی Test Case و تکنیک‌های ISTQB
• Manual Testing
• API Testing و Automation Testing

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

جمع‌بندی نهایی مقاله انواع تست نرم افزار

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

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

• آیا سیستم اجرا می‌شود یا خیر؟ → Static / Dynamic
• کدام بخش سیستم بررسی می‌شود؟ → Testing Levels
• هدف تست چیست؟ → Functional / Non-functional
• آیا تغییر ایجاد شده است؟ → Confirmation / Regression
• چگونه اجرا می‌شود؟ → Manual / Automated
• چه میزان از ساختار داخلی مشخص است؟ → Black-box / Gray-box / White-box

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

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

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

---

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

منابع

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

• 
  ISTQB – International Software Testing Qualifications Board
  
  مرجع رسمی مفاهیم، اصطلاحات، Syllabusها و چارچوب گواهینامه‌های تست نرم افزار.
  
• 
  ISTQB Certified Tester Foundation Level (CTFL) v4.0
  
  منبع اصلی برای مفاهیم پایه تست نرم افزار، از جمله Static و Dynamic Testing، Test Levels، Test Types و Test Techniques.
  
• 
  ISTQB CTFL Syllabus v4.0.1
  
  Syllabus رسمی و مرجع اصلی مطالب آموزشی CTFL 4.0.1.
  
• 
  ISTQB Glossary
  
  واژه‌نامه رسمی ISTQB برای تعاریف و اصطلاحات استاندارد تست نرم افزار.
  
• 
  ISO/IEC/IEEE 29119 – Software Testing
  
  مجموعه استانداردهای بین‌المللی مرتبط با فرآیندها، مستندات، مفاهیم و تکنیک‌های تست نرم افزار.
  

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

منبع اصلی مقاله: برای مفاهیم و اصطلاحات اصلی، مرجع اصلی این مقاله Syllabus و Glossary رسمی ISTQB در نظر گرفته شده است.