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

فرض کنید یک Build جدید از نرم‌افزار به دست تیم QA رسیده است. آیا منطقی است که تیم قبل از هر چیز صدها Test Case را اجرا کند؟

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

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

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

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

Smoke Testing در پروژه‌های مدرن فقط به اجرای چند Test Case به‌صورت دستی محدود نمی‌شود. این تست می‌تواند به‌صورت Automated اجرا شود و در CI/CD Pipeline نیز قرار بگیرد تا بعد از Build یا Deployment، سلامت اولیه نرم‌افزار به‌سرعت بررسی شود.

در این مقاله ابتدا با مفهوم Smoke Testing و هدف آن آشنا می‌شویم، سپس نحوه اجرای آن، جایگاهش در Agile و DevOps، تفاوت آن با Sanity و Regression Testing، مزایا و محدودیت‌ها، Checklist، اشتباهات رایج و یک Case Study واقعی‌نما را بررسی می‌کنیم.

در پایان، دید روشنی خواهید داشت که Smoke Testing دقیقاً چه زمانی، چرا و چگونه باید در فرآیند Software Testing مورد استفاده قرار گیرد.

نکته کلیدی: Smoke Testing برای اثبات اینکه نرم‌افزار بدون Bug است انجام نمی‌شود؛ هدف آن این است که مشخص کند آیا یک Build حداقل شرایط لازم برای ادامه فرآیند Testing را دارد یا خیر.

Table of Contents

۱. Smoke Testing چیست؟

وقتی یک Build جدید از نرم‌افزار در اختیار تیم QA قرار می‌گیرد، اولین سؤال این نیست که «آیا همه قابلیت‌های سیستم درست کار می‌کنند؟»؛ بلکه سؤال مهم‌تر این است:

آیا این Build آن‌قدر سالم هست که ارزش انجام تست‌های بیشتر را داشته باشد؟

اینجاست که Smoke Testing وارد می‌شود.

Smoke Testing یا Smoke Test مجموعه‌ای محدود از تست‌هاست که مهم‌ترین و حیاتی‌ترین قابلیت‌های یک Component یا System را بررسی می‌کند تا مشخص شود نرم‌افزار قبل از شروع تست‌های برنامه‌ریزی‌شده، در وضعیت قابل‌قبولی قرار دارد یا خیر. در تعریف ISTQB نیز Smoke Test به مجموعه‌ای از تست‌ها برای بررسی Main Functionality سیستم پیش از شروع تست‌های برنامه‌ریزی‌شده اشاره دارد.

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

Build سالم است → تست‌های عمیق‌تر را ادامه می‌دهیم.

Build مشکل اساسی دارد → ابتدا مشکل را بررسی و برطرف می‌کنیم.

یک مثال ساده

فرض کنیم تیم توسعه یک Build جدید از یک فروشگاه اینترنتی تحویل داده است.

تیم QA قبل از اینکه صدها Test Case مربوط به Functional Testing و Regression Testing را اجرا کند، چند قابلیت حیاتی را بررسی می‌کند:

آیا Application اجرا می‌شود؟
آیا کاربر می‌تواند Login کند؟
آیا صفحه اصلی باز می‌شود؟
آیا Search کار می‌کند؟
آیا امکان مشاهده محصول وجود دارد؟
آیا افزودن محصول به Cart امکان‌پذیر است؟
آیا فرآیند اصلی خرید در سطح اولیه قابل انجام است؟

اگر مثلاً Application اصلاً اجرا نشود یا Login برای کاربران کار نکند، منطقی نیست تیم QA چند ساعت یا حتی چند روز را صرف تست‌های جزئی‌تر روی همان Build کند.

در چنین شرایطی، Build احتمالاً برای ادامه تست مناسب نیست و ابتدا باید مشکل آن بررسی و برطرف شود.

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

Smoke Testing دقیقاً چه چیزی را مشخص می‌کند؟

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

Pass شدن Smoke Test به معنی بدون Bug بودن نرم‌افزار نیست.

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

برای مثال، اگر Login، Search و Checkout در Smoke Test موفق باشند، هنوز نمی‌توان نتیجه گرفت که:

همه حالت‌های Login درست کار می‌کنند.
Search در تمام شرایط عملکرد صحیح دارد.
Checkout در تمام سناریوها بدون مشکل است.
هیچ Regressionای در سیستم وجود ندارد.
هیچ Bug مهم دیگری در محصول وجود ندارد.

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

به همین دلیل می‌توان Smoke Testing را یک Quality Gate اولیه دانست، نه یک ارزیابی کامل از کیفیت محصول.

چرا به آن Smoke Testing می‌گویند؟

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

اگر دستگاه همان ابتدا دود کند، احتمالاً انجام آزمایش‌های پیچیده‌تر روی آن منطقی نیست!

در نرم‌افزار نیز ایده مشابهی وجود دارد:

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

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

یک نکته مهم درباره نام‌های Smoke و Sanity

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

در ISTQB Glossary، اصطلاحاتی مانند Sanity Test، Intake Test و Confidence Test به‌عنوان Synonymهایی برای Smoke Test ذکر شده‌اند.

با این حال، در بسیاری از تیم‌ها و منابع فنی، Smoke Testing و Sanity Testing به‌عنوان دو مفهوم متفاوت مورد استفاده قرار می‌گیرند:

Smoke Testing: بررسی نسبتاً گسترده و سطحی قابلیت‌های حیاتی برای ارزیابی آمادگی اولیه یک Build.
Sanity Testing: بررسی محدود و هدفمند یک بخش خاص، معمولاً پس از یک تغییر یا Bug Fix.

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

چرا Smoke Testing مهم است؟

فرض کنید یک Build جدید در اختیار تیم QA قرار گرفته و تیم باید ۲۰۰ Test Case را روی آن اجرا کند. اگر این Build از همان ابتدا یک مشکل اساسی داشته باشد، مثلاً Application اجرا نشود یا فرآیند Login کاملاً از کار افتاده باشد، اجرای صدها تست دیگر عملاً می‌تواند اتلاف زمان و منابع باشد.

Smoke Testing دقیقاً برای جلوگیری از چنین وضعیتی کاربرد دارد.

۱. جلوگیری از اتلاف زمان تیم QA

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

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

مثلاً اگر در یک فروشگاه اینترنتی مسیرهای زیر جزء Critical Flowها باشند:

Login → Search → Product → Cart → Checkout

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

۲. شناسایی سریع مشکلات بحرانی

Smoke Test معمولاً روی Critical Functionality تمرکز دارد؛ بنابراین می‌تواند مشکلاتی را که مانع ادامه تست هستند، در مراحل اولیه آشکار کند.

Application اجرا نمی‌شود.
صفحه اصلی Load نمی‌شود.
Login کار نمی‌کند.
ارتباط با Database برقرار نیست.
یک API حیاتی پاسخ مناسب نمی‌دهد.
امکان ایجاد Order وجود ندارد.

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

۳. جلوگیری از شروع تست روی یک Build ناسالم

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

Smoke Testing یک Quality Gate اولیه ایجاد می‌کند:

Build جدید → Smoke Test → تصمیم درباره ادامه تست

اگر Smoke موفق باشد، تست‌های Functional، Regression و سایر تست‌های موردنیاز می‌توانند طبق Test Strategy پروژه ادامه پیدا کنند.

اگر Smoke با یک Failure مهم مواجه شود، تیم می‌تواند ابتدا Build را بررسی و مشکل را برطرف کند.

۴. کاهش Feedback Time

فرض کنید یک Build ساعت ۹ صبح Deploy شده و یک مشکل بسیار مهم در آن وجود دارد.

اگر Smoke Test وجود داشته باشد، QA ممکن است همان ابتدای فرآیند مشکل را پیدا کند و تیم توسعه سریعاً در جریان قرار بگیرد.

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

بنابراین Smoke Testing می‌تواند باعث شود Feedback درباره سلامت اولیه Build سریع‌تر به تیم توسعه برسد.

این موضوع در تیم‌هایی که Build و Deploymentهای مکرر دارند اهمیت بیشتری پیدا می‌کند.

۵. اهمیت Smoke Testing در CI/CD

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

در چنین شرایطی، اجرای یک مجموعه کوچک و سریع از Smoke Testهای Automated می‌تواند به‌عنوان یک Quality Gate در Pipeline عمل کند.

Code Commit
     ↓
Build
     ↓
Deploy to Test Environment
     ↓
Smoke Tests
     ↓
   Pass?
   ↙    ↘
 Yes     No
 ↓        ↓
Continue  Stop Pipeline
Testing   / Fix Build

اگر Smoke Testها Fail شوند، Pipeline می‌تواند بر اساس سیاست تیم و تنظیمات CI/CD ادامه مراحل را متوقف کند تا مشکل Build بررسی و برطرف شود.

این یکی از دلایلی است که Smoke Testing در کنار Automation، CI/CD و DevOps اهمیت زیادی پیدا کرده است.

۶. کمک به استفاده مؤثرتر از منابع تست

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

Smoke Testing با ارائه این Feedback اولیه می‌تواند به استفاده مؤثرتر از زمان QA، منابع Automation و ظرفیت CI/CD کمک کند.

البته نباید به‌صورت مطلق گفت Smoke Testing همیشه هزینه تست را کاهش می‌دهد؛ ارزش آن به عواملی مانند اندازه پروژه، تعداد Buildها، کیفیت Smoke Suite و نحوه استفاده تیم از آن بستگی دارد.

یک نکته مهم: Smoke Testing نباید تبدیل به Regression Test Suite شود

این یکی از مهم‌ترین نکاتی است که هنگام طراحی Smoke Test باید به آن توجه کرد.

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

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

یک Smoke Suite مناسب باید تا حد امکان:

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

هدف Smoke Testing این نیست که تمام قابلیت‌های نرم‌افزار را بررسی کند.

پس Smoke Testing چه مشکلی را حل می‌کند؟

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

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

Smoke Testing چه زمانی انجام می‌شود؟

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

قاعده ساده این است:

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

البته نحوه استفاده از Smoke Testing در پروژه‌های مختلف متفاوت است و به Test Strategy، نوع Application، فرآیند Release و CI/CD Pipeline بستگی دارد.

۱. بعد از ایجاد یک Build جدید

یکی از رایج‌ترین زمان‌های اجرای Smoke Test، زمانی است که یک Build جدید آماده تست می‌شود.

Developer
   ↓
Code Changes
   ↓
Build
   ↓
QA Environment
   ↓
Smoke Testing
   ↓
Pass?
 ↙     ↘
Yes     No
 ↓       ↓
Testing  Fix
Continues

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

۲. بعد از Deployment

Smoke Testing فقط محدود به زمان Build شدن نرم‌افزار نیست.

فرض کنید Build در محیط توسعه یا CI با موفقیت ساخته شده، اما هنگام Deployment به QA مشکلی ایجاد شده است.

Configuration اشتباه است.
Database Connection برقرار نیست.
یکی از Serviceها اجرا نشده است.
Environment Variable اشتباه تنظیم شده است.
یک API در محیط QA در دسترس نیست.

در این شرایط ممکن است Build از نظر فرآیند Build سالم باشد، اما نسخه Deploy شده قابل استفاده یا تست نباشد.

بنابراین اجرای Smoke Test بعد از Deployment می‌تواند مشخص کند که محیط جدید برای ادامه Testing آماده است یا خیر.

۳. قبل از شروع تست‌های گسترده‌تر

Smoke Testing معمولاً در ابتدای چرخه تست یک Build قرار می‌گیرد.

New Build
   ↓
Smoke Testing
   ↓
Functional Testing
   ↓
Regression Testing
   ↓
Other Testing

این ترتیب یک قانون جهانی و اجباری نیست و ممکن است در پروژه‌های مختلف متفاوت باشد. نکته اصلی این است که Smoke Test یک Initial Verification محسوب می‌شود و جایگزین تست‌های بعدی نیست.

۴. بعد از تغییرات مهم در سیستم

هر تغییر کوچکی الزاماً نیازمند اجرای یک Smoke Suite کامل نیست.

اما زمانی که تغییرات قابل‌توجهی در Build ایجاد شده یا یک Release جدید در اختیار QA قرار گرفته است، اجرای Smoke Test می‌تواند مفید باشد.

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

Authentication
Payment
Order Management
Database
API Gateway

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

۵. در CI/CD

در تیم‌هایی که از Continuous Integration / Continuous Delivery استفاده می‌کنند، Smoke Testing می‌تواند به‌صورت Automated و به‌عنوان بخشی از Pipeline اجرا شود.

Commit
  ↓
Build
  ↓
Unit Tests
  ↓
Deploy
  ↓
Automated Smoke Tests
  ↓
   Pass?
  ↙     ↘
Yes      No
 ↓        ↓
Continue  Stop
Pipeline  Pipeline

در چنین ساختاری، Smoke Test می‌تواند نقش یک Quality Gate را داشته باشد. اگر تست‌های حیاتی Fail شوند، Pipeline می‌تواند بر اساس سیاست تیم ادامه مراحل را متوقف کند تا مشکل بررسی شود.

۶. آیا Smoke Testing باید بعد از هر تغییر اجرا شود؟

لزومی ندارد.

Smoke Testing معمولاً به Build، Deployment یا نسخه‌ای که قرار است وارد چرخه تست شود مرتبط است؛ نه اینکه بعد از تک‌تک تغییرات کد، الزاماً کل Smoke Suite اجرا شود.

در یک Pipeline ممکن است با هر Commit، Build ساخته شود و Smoke Testهای Automated اجرا شوند؛ اما این تصمیم به معماری، سرعت Pipeline، هزینه اجرای تست و سیاست تیم بستگی دارد.

بنابراین بهتر است یک قانون مطلق مانند «بعد از هر تغییر کوچک حتماً Smoke Test کامل اجرا شود» تعریف نکنیم و اجرای آن را بر اساس فرآیند Delivery و Risk پروژه تعیین کنیم.

تفاوت زمان Smoke Testing با Sanity Testing

این موضوع یکی از نقاطی است که در بخش مقایسه Smoke و Sanity به آن بازخواهیم گشت.

در کاربرد عملی رایج:

Smoke Testing: معمولاً زمانی مطرح می‌شود که یک Build یا نسخه جدید آماده تست شده و می‌خواهیم بدانیم آیا سیستم به اندازه کافی سالم است که تست‌های بیشتر را شروع کنیم.
Sanity Testing: معمولاً بعد از یک تغییر مشخص یا Bug Fix و با Scope محدودتر انجام می‌شود تا بررسی شود بخش تغییرکرده و قسمت‌های مرتبط، رفتار مورد انتظار را دارند.

مثلاً اگر Bug مربوط به محاسبه Discount اصلاح شده باشد، تیم ممکن است ابتدا همان بخش و قسمت‌های مستقیماً مرتبط را بررسی کند تا مطمئن شود Fix موردنظر درست عمل می‌کند.

البته همان‌طور که در بخش قبلی اشاره شد، اصطلاح Sanity Testing در منابع و تیم‌های مختلف به شکل یکسان استفاده نمی‌شود و در Terminology رسمی ISTQB نیز به‌عنوان Synonym برای Smoke Test آمده است.

جمع‌بندی این بخش

مهم‌ترین زمان‌های اجرای Smoke Testing عبارت‌اند از:

بعد از دریافت Build جدید
بعد از Deployment به محیط تست
قبل از شروع تست‌های گسترده‌تر
در فرآیند Release
در Pipelineهای CI/CD
بعد از تغییرات مهمی که یک Build جدید ایجاد کرده‌اند

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

قبل از اینکه زمان زیادی برای تست یک Build صرف کنیم، مطمئن شویم Build حداقل شرایط لازم برای ادامه Testing را دارد.

Smoke Testing چگونه انجام می‌شود؟

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

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

Build جدید
    ↓
شناسایی قابلیت‌های حیاتی
    ↓
انتخاب Smoke Test Cases
    ↓
اجرای تست‌ها
    ↓
بررسی نتایج
    ↓
Pass یا Fail شدن Smoke Test
    ↓
تصمیم درباره ادامه تست

۱. Build مناسب برای تست را مشخص کنید

ابتدا باید مشخص شود کدام Build قرار است بررسی شود.

برای مثال:

Build v2.8.0 روی محیط QA Deploy شده است.

قبل از شروع Smoke Testing، QA باید مطمئن شود Build موردنظر واقعاً در محیط مناسب Deploy شده و اطلاعات اولیه موردنیاز برای تست در دسترس است.

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

Build Number
Version
Environment
Deployment Status
Database Version
API Version

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

قرار نیست تمام قابلیت‌های نرم‌افزار وارد Smoke Suite شوند.

ابتدا باید مشخص شود:

اگر کدام قابلیت کار نکند، ادامه تست این Build عملاً بی‌معنی یا بسیار دشوار می‌شود؟

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

باز شدن Application
Login
Search
مشاهده Product
افزودن محصول به Cart
ایجاد Order
ارتباط با Payment Service

در مقابل، قابلیت‌هایی مانند تغییر Theme یا یک Tooltip کوچک معمولاً اولویت بالایی برای Smoke Testing ندارند.

۳. Smoke Test Caseها را انتخاب کنید

پس از مشخص شدن Critical Functionality، Test Caseهای مناسب انتخاب می‌شوند.

یک Smoke Test Case مناسب معمولاً باید:

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

مثلاً به جای اینکه برای Login ده‌ها سناریوی مختلف طراحی کنیم، در Smoke Test ممکن است فقط مسیر اصلی Authentication را بررسی کنیم:

Open Login Page
      ↓
Enter Valid Credentials
      ↓
Click Login
      ↓
User enters Dashboard

این تست نمی‌خواهد تمام رفتار Login را بررسی کند؛ فقط می‌خواهد مطمئن شود مسیر اصلی Login در Build جدید قابل استفاده است.

۴. Smoke Testها را اجرا کنید

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

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

Test	نتیجه
Application Launch	PASS
Login	PASS
Search Product	PASS
View Product	PASS
Add to Cart	PASS
Checkout	FAIL

در این شرایط، تیم QA باید بررسی کند که Failure مربوط به یک مشکل واقعی در Build است یا مثلاً مشکل Environment، Dependency یا Test Data وجود دارد.

۵. Failure را تحلیل کنید

Fail شدن یک Smoke Test همیشه به معنی وجود Bug در Application نیست.

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

Bug در Application
مشکل Environment
در دسترس نبودن Database
Down بودن یک API یا Service
Configuration اشتباه
Test Data نامعتبر
مشکل Network

بنابراین QA نباید صرفاً با مشاهده FAIL فوراً نتیجه بگیرد که Developer باید یک Bug را Fix کند.

ابتدا باید مشخص شود:

آیا واقعاً Build مشکل دارد یا Failure ناشی از محیط و شرایط تست است؟

این موضوع در Smoke Testing اهمیت زیادی دارد، زیرا تصمیم درباره ادامه یا توقف تست باید بر اساس علت واقعی Failure گرفته شود.

۶. درباره Build تصمیم بگیرید

در نهایت تیم باید درباره وضعیت Build تصمیم بگیرد.

اگر Smoke Testها موفق باشند:

Build از نظر Smoke Suite در وضعیت قابل‌قبولی قرار دارد و تیم می‌تواند طبق Test Strategy پروژه، تست‌های عمیق‌تر را ادامه دهد.

اگر Smoke Test با یک Failure مهم مواجه شود:

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

البته معیار دقیق Pass یا Fail باید توسط تیم و بر اساس Risk، Criticality و Impact پروژه تعیین شود؛ هر Failure کوچک الزاماً به معنی Reject کردن کل Build نیست.

یک مثال عملی

فرض کنیم یک Build جدید از یک فروشگاه اینترنتی به QA تحویل شده است.

تیم QA یک Smoke Suite پنج‌مرحله‌ای دارد:

1. Open Application
2. Login
3. Search Product
4. Add Product to Cart
5. Complete Checkout

نتایج اجرای تست‌ها:

Open Application       → PASS
Login                  → PASS
Search Product         → PASS
Add to Cart            → PASS
Checkout               → FAIL

در این شرایط QA نباید بلافاصله سراغ اجرای صدها Test Case دیگر برود. ابتدا باید علت Failure در Checkout مشخص شود.

فرض کنیم مشخص شود:

Payment API در Build جدید با نسخه جدید Backend سازگار نیست.

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

Smoke Testing یک تست کامل نیست

این نکته را باید همیشه در نظر داشت.

اگر Smoke Suite شامل ۱۰ Test Case باشد و هر ۱۰ مورد Pass شوند، نمی‌توان گفت:

«نرم‌افزار سالم است.»

فقط می‌توان گفت:

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

بعد از آن، تست‌های دقیق‌تر مانند Functional Testing، Regression Testing، Integration Testing و سایر تست‌های موردنیاز طبق Test Strategy پروژه انجام می‌شوند.

یک اصل مهم در طراحی Smoke Suite

Smoke Suite باید کوچک اما باارزش باشد.

اگر تیم برای افزایش پوشش، صدها Test Case را وارد Smoke Suite کند، ممکن است بعد از مدتی مرز بین Smoke Testing و Regression Testing از بین برود و اجرای Smoke بیش از حد زمان‌بر شود.

بهتر است به جای این سؤال:

«چطور Test Caseهای بیشتری در Smoke قرار دهیم؟»

این سؤال را مطرح کنیم:

«حداقل چه تست‌هایی لازم است تا بفهمیم این Build ارزش ادامه تست را دارد؟»

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

چه چیزهایی در Smoke Testing تست می‌شوند؟

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

Smoke Test قرار نیست نسخه کوچک‌شده‌ای از کل Regression Suite باشد. هدف آن بررسی تعداد محدودی از Critical Functionality است؛ یعنی قابلیت‌هایی که خرابی آن‌ها می‌تواند نشان دهد Build برای ادامه تست مناسب نیست.

بنابراین هنگام طراحی Smoke Suite بهتر است این سؤال را مطرح کنیم:

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

اگر پاسخ «خیر» باشد، آن قابلیت می‌تواند کاندیدای مناسبی برای Smoke Testing باشد.

۱. اجرای اولیه Application

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

Application Start می‌شود؟
صفحه اصلی Load می‌شود؟
Application بلافاصله Crash نمی‌کند؟
Serviceهای اصلی در وضعیت قابل استفاده هستند؟

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

۲. Login و Authentication

در بسیاری از سیستم‌ها، Login یکی از قابلیت‌های حیاتی است.

Smoke Test ممکن است فقط مسیر اصلی Authentication را بررسی کند:

Login Page
    ↓
Valid Username
    ↓
Valid Password
    ↓
Login
    ↓
Dashboard

اما قرار نیست در Smoke Testing تمام سناریوهای Authentication مانند Password Reset، Account Lockout، Password Complexity، Session Timeout و Edge Caseهای مختلف بررسی شوند. این موارد می‌توانند در Functional Testing، Security Testing یا تست‌های تخصصی‌تر بررسی شوند.

۳. Navigation اصلی

گاهی Application اجرا می‌شود و Login نیز موفق است، اما Navigation اصلی سیستم دچار مشکل شده است.

Dashboard قابل دسترسی نیست.
لینک‌های اصلی Broken هستند.
صفحات مهم Load نمی‌شوند.
Routing دچار مشکل است.

در چنین شرایطی، بررسی چند مسیر اصلی می‌تواند بخشی از Smoke Suite باشد.

۴. قابلیت‌های Core Business

این قسمت یکی از مهم‌ترین بخش‌های Smoke Testing است.

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

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

Login
  ↓
Search Product
  ↓
View Product
  ↓
Add to Cart
  ↓
Checkout

در یک سیستم بانکی ممکن است مسیر اصلی متفاوت باشد:

Login
  ↓
View Account
  ↓
Transfer Money
  ↓
Transaction Confirmation

بنابراین Smoke Suite باید بر اساس Business Criticality طراحی شود، نه صرفاً بر اساس اینکه کدام صفحات برای تست کردن ساده‌تر هستند.

۵. APIهای حیاتی

Smoke Testing فقط مخصوص UI نیست.

اگر Application از API استفاده می‌کند، APIهای حیاتی نیز می‌توانند در Smoke Suite قرار بگیرند.

POST /login
GET  /products
POST /cart
POST /orders

هدف در اینجا بررسی کامل API نیست. برای مثال، در POST /login قرار نیست تمام Validationها، Boundary Valueها، Error Handlingها و Security Scenarioها بررسی شوند.

ممکن است در Smoke Testing فقط بررسی کنیم:

آیا API با یک Request معتبر، پاسخ مورد انتظار را برمی‌گرداند؟

این موضوع در معماری‌های Microservices اهمیت بیشتری پیدا می‌کند؛ زیرا ممکن است UI در دسترس باشد اما یکی از Serviceهای حیاتی Backend کار نکند.

۶. ارتباط با Database

اگر Application برای عملکرد اصلی خود به Database وابسته باشد، ارتباط ضروری با Database نیز می‌تواند بخشی از Smoke Testing باشد.

برای مثال، کاربر Login می‌کند اما اطلاعات حساب او نمایش داده نمی‌شود. اگر مشخص شود Database Connection برقرار نیست، این می‌تواند یک مشکل بنیادی برای Build محسوب شود.

البته Smoke Test قرار نیست سلامت کامل Database را بررسی کند؛ هدف این است که ارتباط ضروری برای Core Functionality برقرار باشد.

۷. Integrationهای حیاتی

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

Payment Gateway
Email Service
SMS Service
Inventory Service
Shipping Service
Authentication Service

اما همه Integrationها لزوماً نباید در Smoke Test قرار بگیرند.

باید مشخص شود کدام Integration برای Core Flow حیاتی است.

مثلاً اگر بدون Payment Gateway امکان تکمیل Order وجود نداشته باشد، این Integration کاندید مناسبی برای Smoke Testing است.

۸. مهم‌ترین مسیرهای End-to-End

در بعضی پروژه‌ها یک Smoke Test می‌تواند یک مسیر کوتاه End-to-End را نیز شامل شود.

Login
  ↓
Select Product
  ↓
Add to Cart
  ↓
Checkout

این تست بررسی می‌کند که چند Component اصلی در کنار یکدیگر، حداقل در یک مسیر حیاتی با هم کار می‌کنند.

اما باید دقت کرد:

Smoke Test End-to-End لزوماً به معنی E2E Testing کامل نیست.

در Smoke Testing فقط یک یا چند مسیر مهم و نماینده بررسی می‌شوند؛ در حالی که E2E Testing می‌تواند مجموعه بسیار گسترده‌تری از Business Flowها و سناریوهای مختلف را پوشش دهد.

معیار انتخاب یک قابلیت برای Smoke Test

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

آیا این قابلیت برای سیستم حیاتی است؟ اگر پاسخ مثبت باشد، احتمال ورود آن به Smoke Suite بیشتر است.
آیا خرابی آن مانع تست سایر بخش‌ها می‌شود؟ اگر بله، اهمیت آن بیشتر می‌شود.
آیا قابلیت در مسیر اصلی استفاده از سیستم قرار دارد؟ Core User Journeyها معمولاً کاندیدهای مناسبی هستند.
آیا تست آن سریع و پایدار است؟ Smoke Test باید سریع اجرا شود و نتیجه قابل اعتمادی ارائه دهد.
آیا اجرای آن ارزش اطلاعاتی بالایی دارد؟ یک Smoke Test خوب باید با زمان کم، اطلاعات مهمی درباره وضعیت اولیه Build ارائه کند.

یک مثال عملی برای انتخاب Smoke Test

فرض کنیم یک فروشگاه اینترنتی ۱۰۰ قابلیت مختلف دارد. این قابلیت‌ها ممکن است شامل موارد زیر باشند:

Login
Search
Product Details
Cart
Checkout
Payment
Wishlist
Product Comparison
Reviews
Dark Mode
Notifications
Profile Settings
Address Management
Coupon
Product Sorting

آیا همه این قابلیت‌ها باید وارد Smoke Suite شوند؟

خیر.

ممکن است تیم فقط موارد زیر را انتخاب کند:

Application Launch
Login
Search
Product Details
Add to Cart
Checkout
Payment

این مجموعه یک مسیر حیاتی و نماینده از سیستم ایجاد می‌کند، در حالی که قابلیت‌هایی مانند Dark Mode یا Product Comparison ممکن است اولویت پایین‌تری برای Smoke Testing داشته باشند و در Functional یا Regression Testing بررسی شوند.

Smoke Test باید «Critical» باشد، نه صرفاً «Important»

این تفاوت ظریفی است.

هر قابلیت مهمی الزاماً Smoke Test Candidate نیست.

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

بنابراین بهتر است هنگام طراحی Smoke Suite علاوه بر Business Importance، معیارهای زیر را نیز در نظر بگیریم:

Criticality + Dependency + User Journey + Risk + Testability

این ترکیب به تیم کمک می‌کند Smoke Suite را بیش از حد بزرگ نکند و در عین حال مهم‌ترین نقاط شکست Build را پوشش دهد.

جمع‌بندی

Smoke Testing معمولاً روی مواردی مانند این‌ها تمرکز دارد:

Application Startup
Login و Authentication
Navigation اصلی
Core Business Flow
APIهای حیاتی
Database Connectivity
Integrationهای ضروری
مسیرهای اصلی End-to-End

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

Smoke Suite باید بر اساس معماری، Business Risk، Critical Path و وابستگی‌های سیستم طراحی شود. هدف، ایجاد بزرگ‌ترین Test Suite ممکن نیست؛ هدف این است که با کمترین تعداد تست‌های باارزش، بیشترین اطلاعات را درباره آمادگی اولیه Build برای ادامه Testing به دست آوریم.

چه چیزهایی نباید در Smoke Test قرار بگیرند؟

یکی از اشتباهات رایج در طراحی Smoke Test این است که تیم QA تصور کند:

«هر چیزی که باید تست شود، باید در Smoke Test هم قرار بگیرد.»

در حالی که دقیقاً برعکس است.

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

هدف Smoke Test ارزیابی کامل کیفیت محصول نیست؛ هدف این است که مشخص کند Build برای ادامه تست مناسب هست یا خیر.

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

Smoke Test باید روی قابلیت‌های حیاتی تمرکز کند. بنابراین تست‌هایی مانند تغییر Theme، بررسی Tooltip، جزئیات ظاهری یک Icon، متن یک Label یا یک Animation کوچک معمولاً جای مناسبی در Smoke Suite ندارند.

این موارد ممکن است کاملاً ارزش تست داشته باشند، اما معمولاً Smoke Test Candidate نیستند.

۲. تمام حالت‌های مثبت و منفی یک قابلیت

فرض کنیم Login یکی از قابلیت‌های اصلی سیستم است. در Smoke Testing ممکن است فقط این سناریو را بررسی کنیم:

Valid Username
       +
Valid Password
       ↓
Successful Login

اما مواردی مانند Username خالی، Password خالی، Password اشتباه، Account Locked، Password Expired و سایر سناریوهای منفی می‌توانند در Functional Testing، Security Testing و تست‌های تخصصی‌تر بررسی شوند.

۳. Edge Caseها

Edge Caseها معمولاً برای تست کامل یک قابلیت ارزشمند هستند، اما معمولاً بخشی از Smoke Test نیستند.

برای مثال در یک سیستم انتقال وجه، انجام یک انتقال با مبلغ معتبر می‌تواند بخشی از Core Flow باشد؛ اما تست کردن مقدار صفر، مبلغ دقیقاً برابر با Maximum Limit یا مبلغی یک واحد بیشتر از Limit بیشتر به Functional Testing و Boundary Value Analysis مربوط می‌شود.

Smoke Test در وهله اول باید مشخص کند که مسیر اصلی انتقال وجه اساساً کار می‌کند یا خیر.

۴. تست‌های عمیق Business Logic

فرض کنیم سیستم فروشگاه اینترنتی قانون پیچیده‌ای برای تخفیف دارد:

اگر مبلغ خرید بیشتر از 5 میلیون باشد
و کاربر Premium باشد
و محصول در دسته خاصی قرار داشته باشد
و Coupon معتبر باشد
→ تخفیف 17٪ اعمال شود.

بررسی تمام ترکیب‌های این Rule برای Smoke Testing مناسب نیست.

Smoke Test ممکن است فقط بررسی کند که در مسیر اصلی Checkout، محاسبه سفارش و پرداخت در سطح اولیه کار می‌کند. تست دقیق Business Rule باید در Test Suite مناسب خودش انجام شود.

۵. تست‌های Performance عمیق

Smoke Testing با Performance Testing یکی نیست.

اینکه یک API با یک Request ساده پاسخ صحیح بدهد می‌تواند بخشی از Smoke Test باشد، اما مواردی مانند Load Testing، Stress Testing، Spike Testing، Endurance Testing و تحلیل Throughput تحت بار بالا در Smoke Test قرار نمی‌گیرند.

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

۶. تست‌های Security عمیق

بررسی یک Login موفق می‌تواند در Smoke Suite وجود داشته باشد، اما Smoke Test جایگزین Security Testing نیست.

SQL Injection
XSS
CSRF
Authorization Bypass
Session Security
Penetration Testing
بررسی دقیق Access Control

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

۷. تست‌های Compatibility گسترده

فرض کنیم یک Web Application داریم. آیا Smoke Testing باید روی تمام Browserها، Deviceها، Resolutionها و Operating Systemهای پشتیبانی‌شده اجرا شود؟

لزومی ندارد.

ممکن است تیم یک یا چند Environment اصلی را برای Smoke انتخاب کند و Compatibility Testing کامل را جداگانه انجام دهد.

البته اگر یک Browser یا Device خاص برای Business Critical باشد، همان Environment می‌تواند در Smoke Suite قرار بگیرد.

۸. تمام Regression Test Caseها

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

فرض کنیم Regression Suite یک پروژه شامل ۱۲۰۰ Test Case باشد. نباید صرفاً به این دلیل که این تست‌ها قبلاً نوشته شده‌اند، همه یا بخش بزرگی از آن‌ها را وارد Smoke Suite کنیم.

Smoke Suite ممکن است فقط شامل چند Test Case حیاتی باشد. هیچ عدد ثابتی برای تعداد Smoke Testها در همه پروژه‌ها وجود ندارد.

اگر Smoke Suite به اندازه Regression Suite شود، یکی از اهداف اصلی خود را از دست می‌دهد:

سریع بودن و ارائه Feedback اولیه

چگونه تشخیص دهیم یک Test Case مناسب Smoke است؟

برای هر Test Case این سؤال را بپرسید:

اگر این تست Fail شود، آیا احتمال دارد نتیجه بگیریم که Build برای ادامه تست مناسب نیست؟

اگر پاسخ بله باشد، Test Case احتمالاً کاندید مناسبی برای Smoke است. اگر پاسخ خیر باشد، احتمالاً بهتر است در Test Suite دیگری قرار بگیرد.

Test Case	Smoke؟	دلیل
Application Launch	✅	بدون آن ادامه تست دشوار یا غیرممکن است
Login اصلی	✅	مسیر حیاتی
Add to Cart	✅	Core Business Flow
Checkout	✅	قابلیت حیاتی
تغییر Theme	❌	Critical نیست
بررسی Tooltip	❌	جزئی است
Password Reset با تمام حالات	❌	نیازمند تست عمیق‌تر است
Load با 10,000 User	❌	Performance Test است
SQL Injection	❌	Security Test است
تست گسترده Browser/Device	❌	Compatibility Test است

خطر تبدیل Smoke Suite به Mini Regression Suite

این اتفاق به‌مرور زمان بسیار رایج است.

فرض کنیم Smoke Suite ابتدا فقط ۱۵ تست داشته باشد. بعد از مدتی افراد مختلف Test Caseهای بیشتری را با این استدلال اضافه می‌کنند که «این تست هم مهم است».

Smoke Suite
     ↓
15 Tests
     ↓
40 Tests
     ↓
100 Tests
     ↓
250 Tests
     ↓
Smoke Suite ≈ Regression Suite

در این حالت باید Smoke Suite دوباره بازبینی و کوچک‌سازی شود.

Smoke Test باید همیشه پاسخ‌دهنده یک سؤال مشخص باقی بماند:

آیا این Build ارزش ادامه تست را دارد؟

اگر یک Test Case هیچ کمک معناداری به پاسخ این سؤال نمی‌کند، باید درباره حضور آن در Smoke Suite دوباره فکر کرد.

Smoke Suite باید با سیستم تکامل پیدا کند

Smoke Testing نباید با یک فهرست ثابت و غیرقابل‌تغییر اشتباه گرفته شود.

با تغییر Architecture، Business Flow و Riskهای سیستم، Smoke Suite نیز ممکن است نیاز به تغییر داشته باشد.

مثلاً اگر Payment Service جدیدی به سیستم اضافه شود و پرداخت به یکی از Critical Pathهای محصول تبدیل شود، احتمالاً Smoke Suite نیز باید متناسب با این تغییر به‌روزرسانی شود.

بنابراین Smoke Suite باید کوچک، سریع، پایدار و متناسب با Critical Pathهای فعلی سیستم باقی بماند.

Smoke Testing در Agile و CI/CD

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

اما در تیم‌های Agile، DevOps و CI/CD شرایط متفاوت است. کد ممکن است چندین بار در روز تغییر کند، Buildهای متعددی ایجاد شوند و نسخه‌های جدید به‌صورت مداوم روی محیط‌های مختلف Deploy شوند.

در چنین محیطی Smoke Testing می‌تواند به یک Quality Gate سریع و خودکار تبدیل شود.

Smoke Testing در Agile

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

Code Change
    ↓
New Build
    ↓
Deploy
    ↓
Smoke Test
    ↓
Functional Testing

اگر Build Smoke Test را Pass کند، تیم می‌تواند تست‌های برنامه‌ریزی‌شده را ادامه دهد. اگر Smoke Test Fail شود، تیم سریعاً متوجه می‌شود که احتمالاً یک مشکل بنیادی وجود دارد و می‌تواند قبل از صرف زمان زیاد روی تست‌های دیگر، آن را بررسی کند.

Smoke Testing در CI/CD

در CI/CD، هدف این است که فرآیند Build، Test و Delivery تا حد امکان سریع و خودکار انجام شود.

Code Commit
     ↓
Build
     ↓
Unit Tests
     ↓
Deploy to Test Environment
     ↓
Smoke Tests
     ↓
   PASS?
   ↙   ↘
 YES    NO
  ↓      ↓
Next    Stop /
Stage   Investigate

در این مدل، Smoke Test می‌تواند بعد از Deploy اجرا شود و وضعیت اولیه Application را بررسی کند. اگر Smoke Test موفق باشد، Pipeline می‌تواند وارد مراحل بعدی شود؛ اگر شکست بخورد، Pipeline می‌تواند متوقف شود یا فرآیند مربوط به Failure را فعال کند.

چرا Automation برای Smoke Testing اهمیت زیادی دارد؟

فرض کنید یک تیم روزانه ۱۰ Build جدید تولید می‌کند و Smoke Suite شامل ۲۰ Test Case باشد. اجرای دستی این تست‌ها برای هر Build می‌تواند زمان قابل‌توجهی از QA بگیرد.

اگر همین Testها Automated باشند، می‌توان آن‌ها را به Pipeline متصل کرد تا در نقاط مناسب از فرآیند Build و Deployment به‌صورت خودکار اجرا شوند.

New Build
    ↓
Automated Deployment
    ↓
Automated Smoke Test
    ↓
Result

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

آیا همه Smoke Testها باید Automated باشند؟

خیر.

Automation برای Smoke Testing بسیار مناسب است، اما این به معنی حذف کامل Manual Smoke Testing نیست.

در بعضی پروژه‌ها ممکن است:

Application جدید باشد.
Smoke Suite هنوز در حال شکل‌گیری باشد.
بعضی Test Caseها Automation مناسبی نداشته باشند.
بررسی خاصی نیاز به قضاوت انسانی داشته باشد.
هزینه Automation یک Test Case بیشتر از ارزش آن باشد.

در این شرایط Manual Smoke Testing همچنان می‌تواند منطقی باشد.

اما هرچه تعداد Buildها و Deploymentها بیشتر شود، معمولاً ارزش Automated Smoke Testing نیز افزایش پیدا می‌کند.

Smoke Test به‌عنوان Quality Gate

یکی از کاربردهای مهم Smoke Testing در CI/CD این است که بتواند به‌عنوان Quality Gate عمل کند.

Quality Gate یعنی قبل از اینکه Pipeline اجازه عبور به مرحله بعدی را بدهد، باید معیارهای مشخصی برقرار باشند.

Smoke Tests
     ↓
Critical Tests Passed?
     ↓
   Yes → Continue
   No  → Stop / Investigate

اما یک نکته مهم وجود دارد: لازم نیست همیشه ۱۰۰٪ Smoke Testها برای عبور Build موفق باشند. سیاست دقیق باید بر اساس Risk، Criticality و نوع Failure توسط تیم تعیین شود.

برای مثال:

Failure در Login → ممکن است Block کند.
Failure در Payment → ممکن است Block کند.
Failure در یک قابلیت غیرحیاتی → ممکن است لزوماً باعث Block شدن Pipeline نشود.

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

Smoke Testing در Microservices

در معماری Microservices، Smoke Testing می‌تواند پیچیده‌تر شود؛ زیرا سلامت اولیه سیستم فقط به یک Application واحد وابسته نیست و چند Service ممکن است در مسیرهای حیاتی با یکدیگر ارتباط داشته باشند.

Frontend
   ↓
API Gateway
   ↓
 ┌──────────┬──────────┬──────────┬──────────┐
 ↓          ↓          ↓          ↓
Auth     Product     Order    Payment
Service  Service    Service   Service

ممکن است Frontend بدون مشکل Load شود، اما Payment Service در دسترس نباشد. در چنین شرایطی یک Smoke Test ساده UI ممکن است برای بررسی مسیر حیاتی سیستم کافی نباشد.

تیم QA می‌تواند Smoke Testهایی برای Critical Serviceها و مسیرهای اصلی طراحی کند تا مطمئن شود اجزای ضروری سیستم در سطح اولیه با یکدیگر ارتباط دارند.

Login
  ↓
Product API
  ↓
Order API
  ↓
Payment API

این نوع Smoke Test می‌تواند یک دید اولیه از سلامت مسیر اصلی سیستم ایجاد کند، اما نباید آن را با Integration Testing کامل یا End-to-End Testing کامل اشتباه گرفت.

Smoke Testing و Continuous Testing

در رویکرد Continuous Testing، تست بخشی از فرآیند مداوم Delivery است و قرار نیست Testing فقط در انتهای توسعه انجام شود.

Smoke Testing می‌تواند یکی از سریع‌ترین Test Layerها در این فرآیند باشد:

Commit
 ↓
Build
 ↓
Unit Tests
 ↓
Smoke Tests
 ↓
Integration Tests
 ↓
Functional / Regression
 ↓
Release

مزیت چنین رویکردی این است که Failureهای واضح و پرهزینه می‌توانند زودتر شناسایی شوند.

البته ترتیب دقیق Testها به معماری، Pipeline و استراتژی تست هر پروژه بستگی دارد و یک ترتیب ثابت برای تمام تیم‌ها وجود ندارد.

یک سناریوی واقعی در CI/CD

فرض کنید یک فروشگاه اینترنتی روزانه چندین بار Deploy می‌شود و Smoke Suite خودکار آن شامل این تست‌هاست:

✓ Application loads
✓ User Login
✓ Product Search
✓ Product Details
✓ Add to Cart
✓ Checkout
✓ Payment

بعد از Deployment نسخه جدید، Pipeline این Smoke Suite را اجرا می‌کند.

Application Load  → PASS
Login             → PASS
Search            → PASS
Product           → PASS
Cart              → PASS
Checkout          → PASS
Payment           → FAIL

Pipeline Failure را تشخیص می‌دهد و بر اساس سیاست Quality Gate، مرحله بعدی را متوقف می‌کند.

تیم توسعه بررسی می‌کند و متوجه می‌شود نسخه جدید Payment Service با API Gateway سازگار نیست.

در نتیجه، تیم قبل از اینکه QA چند صد Regression Test را روی Build اجرا کند، مشکل را شناسایی کرده است.

این دقیقاً یکی از مهم‌ترین ارزش‌های Smoke Testing در CI/CD است.

Smoke Test نباید Pipeline را بیش از حد کند کند

اگر Smoke Suite آن‌قدر بزرگ شود که اجرای آن ۳۰ یا ۶۰ دقیقه طول بکشد، بخش مهمی از مزیت آن از بین می‌رود.

در CI/CD ارزش Smoke Testing تا حد زیادی به این ویژگی‌ها وابسته است:

سریع + قابل‌اعتماد + تکرارپذیر + مرتبط با Critical Path

بنابراین باید دائماً بررسی کنیم:

آیا این Test Case واقعاً برای تصمیم‌گیری درباره سلامت اولیه Build ضروری است؟

اگر پاسخ منفی باشد، شاید بهتر باشد آن تست به Functional یا Regression Suite منتقل شود.

جمع‌بندی

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

در Agile و CI/CD، Smoke Testing می‌تواند:

بعد از Build اجرا شود.
بعد از Deployment اجرا شود.
به صورت Automated اجرا شود.
به Pipeline متصل شود.
به‌عنوان Quality Gate عمل کند.
Failureهای بحرانی را سریع شناسایی کند.
از اجرای تست‌های گسترده روی Buildهای ناسالم جلوگیری کند.

اما Smoke Testing جایگزین Functional، Integration، Regression، Performance یا Security Testing نیست.

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

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

Manual Smoke Testing در مقابل Automated Smoke Testing

Smoke Testing را می‌توان به‌صورت Manual یا Automated انجام داد. انتخاب بین این دو به عواملی مانند تعداد Buildها، سرعت Release، پایداری تست‌ها، زیرساخت Automation و هزینه نگهداری بستگی دارد.

نکته مهم این است که Manual یا Automated بودن، ماهیت Smoke Test را تغییر نمی‌دهد. چیزی که یک تست را به Smoke Test تبدیل می‌کند، هدف و Scope آن است؛ یعنی بررسی سریع قابلیت‌های حیاتی برای تصمیم‌گیری درباره آمادگی اولیه Build.

Manual Smoke Testing چیست؟

در Manual Smoke Testing، QA Test Caseهای Smoke را بدون استفاده از Automation Framework اجرا می‌کند.

برای مثال، بعد از دریافت یک Build جدید، Tester به‌صورت دستی:

Application را باز می‌کند.
Login می‌کند.
یک محصول را جستجو می‌کند.
محصول را به Cart اضافه می‌کند.
فرآیند Checkout را بررسی می‌کند.

اگر مسیرهای حیاتی موفق باشند، Build می‌تواند برای تست‌های بعدی تأیید شود؛ البته معیار دقیق Pass یا Fail باید بر اساس Risk و Criticality پروژه تعیین شود.

مزایای Manual Smoke Testing

مناسب برای پروژه‌های کوچک

اگر تیم روزانه فقط یک Build دریافت می‌کند و Smoke Suite نیز شامل چند Test Case ساده است، اجرای دستی ممکن است سریع‌تر و اقتصادی‌تر از ایجاد و نگهداری Automation باشد.

مناسب برای Featureهای جدید

وقتی یک Feature تازه ساخته شده و هنوز تغییرات زیادی روی آن انجام می‌شود، Automation Test ممکن است دائماً نیاز به اصلاح داشته باشد. در این شرایط، Manual Smoke Testing می‌تواند انعطاف بیشتری داشته باشد.

مناسب برای Smoke Suiteهای اولیه

در ابتدای پروژه ممکن است هنوز مشخص نباشد دقیقاً چه Test Caseهایی باید در Smoke Suite قرار بگیرند. تیم می‌تواند ابتدا آن‌ها را به‌صورت دستی اجرا کند و پس از تثبیت مسیرهای اصلی، موارد مناسب را Automated کند.

Automated Smoke Testing چیست؟

در Automated Smoke Testing، Test Caseهای Smoke با استفاده از ابزارهای Automation اجرا می‌شوند.

Open Application
      ↓
Login
      ↓
Search Product
      ↓
Add to Cart
      ↓
Checkout
      ↓
Validate Result

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

Smoke Test
    ↓
PASS → Continue Pipeline
FAIL → Stop / Investigate

مزایای Automated Smoke Testing

۱. سرعت بیشتر

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

۲. اجرای مکرر

Smoke Test ممکن است روزانه یا حتی چندین بار در روز اجرا شود. Automation باعث می‌شود اجرای مکرر این تست‌ها وابستگی کمتری به حضور Tester داشته باشد.

۳. مناسب برای CI/CD

یکی از مهم‌ترین مزایای Automated Smoke Testing، امکان اتصال Testها به CI/CD Pipeline است. تست‌ها می‌توانند بعد از Build یا Deployment به‌صورت خودکار اجرا شوند.

۴. کاهش فعالیت‌های تکراری

اگر یک Tester مجبور باشد هر روز دقیقاً همان Test Caseها را اجرا کند، بخش زیادی از زمان او صرف فعالیت‌های تکراری خواهد شد. Automation می‌تواند این فعالیت‌ها را کاهش دهد و زمان QA را برای فعالیت‌هایی مانند موارد زیر آزاد کند:

Exploratory Testing
Risk Analysis
Test Design
بررسی Bugهای پیچیده

آیا Automated Smoke Testing همیشه بهتر است؟

خیر.

این تصور که «اگر Smoke Test Automated باشد، پس حتماً بهتر است» صحیح نیست.

Automation خودش هزینه دارد، از جمله:

طراحی Test
پیاده‌سازی
نگهداری
مدیریت Test Data
مدیریت Environment
رفع Flaky Testها
به‌روزرسانی بعد از تغییر UI یا API

اگر یک Test Case دائماً به دلیل تغییرات UI یا API خراب شود، ممکن است هزینه نگهداری آن بیشتر از ارزش Automation باشد.

بنابراین تصمیم برای Automation باید با درنظرگرفتن ROI، میزان تکرار، پایداری، Criticality و هزینه نگهداری گرفته شود.

چه Smoke Testهایی کاندید مناسبی برای Automation هستند؟

معمولاً Testهایی گزینه‌های مناسبی برای Automation هستند که ویژگی‌هایی مانند زیر داشته باشند:

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

برای مثال:

Application Launch
Login
Core API Health
Search
Add to Cart
Checkout
یک مسیر اصلی End-to-End

در مقابل، Test Caseای که هنوز رفتار آن دائماً تغییر می‌کند یا به قضاوت انسانی نیاز دارد، ممکن است فعلاً گزینه مناسبی برای Automation نباشد.

مقایسه Manual و Automated Smoke Testing

ویژگی	Manual	Automated
سرعت اجرا	متوسط	بالا
اجرای مکرر	زمان‌بر	بسیار مناسب
CI/CD	محدود	بسیار مناسب
هزینه اولیه	پایین‌تر	بالاتر
Maintenance	کمتر	نیازمند نگهداری
انعطاف	بالا	معمولاً کمتر
مناسب برای Buildهای زیاد	ضعیف‌تر	بسیار مناسب
مناسب برای Featureهای ناپایدار	معمولاً مناسب‌تر	معمولاً ضعیف‌تر
وابستگی به Tester	زیاد	کمتر

بهترین رویکرد: ترکیبی

در بسیاری از پروژه‌ها لازم نیست بین Manual و Automation یکی را به‌طور کامل انتخاب کنیم. می‌توان از هر دو رویکرد در کنار یکدیگر استفاده کرد.

              Smoke Testing
                    │
          ┌─────────┴─────────┐
          ↓                   ↓
     Automated             Manual
     Smoke Tests         Smoke Checks
          ↓                   ↓
   Critical Paths       Exploratory /
   Stable Scenarios     Visual Checks

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

یک مثال در پروژه واقعی

فرض کنید یک تیم روزانه ۵ Build تولید می‌کند و Smoke Suite شامل ۱۵ Test Case است. اگر هر Smoke Test به‌طور متوسط ۲ دقیقه زمان ببرد:

۱۵ × ۲ = ۳۰ دقیقه برای هر Build

با ۵ Build در روز:

۳۰ × ۵ = ۱۵۰ دقیقه در روز

یعنی حدود ۲.۵ ساعت در روز زمان صرف اجرای Smoke Testهای تکراری می‌شود.

در چنین شرایطی Automation می‌تواند ارزش قابل‌توجهی ایجاد کند؛ به‌خصوص اگر همین تست‌ها قرار باشد در CI/CD نیز اجرا شوند.

اما اگر تیم هفته‌ای یک Build داشته باشد، پروژه کوچک باشد و Smoke Suite فقط ۵ تست داشته باشد، ممکن است Automation فوری اولویت بالایی نداشته باشد.

یک اشتباه رایج

نباید فقط به این دلیل که یک Test Case قابل Automation است، آن را Automated کنیم.

سؤال درست این است:

آیا Automation این Test Case ارزش بیشتری از هزینه ساخت و نگهداری آن ایجاد می‌کند؟

اگر پاسخ مثبت باشد، Automation انتخاب مناسبی است.

جمع‌بندی Manual و Automated Smoke Testing

Manual Smoke Testing انعطاف‌پذیرتر است و برای پروژه‌های کوچک، Featureهای جدید و Smoke Suiteهای در حال تغییر می‌تواند مناسب باشد.

Automated Smoke Testing برای Buildهای متعدد، تست‌های تکراری و Pipelineهای CI/CD ارزش بیشتری پیدا می‌کند.

در بسیاری از تیم‌های حرفه‌ای نیز بهترین راهکار، استفاده هوشمندانه از ترکیب Manual و Automated Smoke Testing است.

Smoke Testing و Build Verification Testing (BVT)

یکی از اصطلاحاتی که هنگام مطالعه Smoke Testing با آن مواجه می‌شوید، Build Verification Testing (BVT) است.

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

BVT چیست؟

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

به زبان ساده:

آیا این Build قابل قبول است که تیم QA تست‌های بیشتری روی آن انجام دهد؟

این سؤال بسیار نزدیک به سؤالی است که Smoke Testing به آن پاسخ می‌دهد.

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

Application اجرا می‌شود؟
Login کار می‌کند؟
Productها قابل مشاهده هستند؟
Cart کار می‌کند؟
امکان ایجاد Order وجود دارد؟

اگر قابلیت‌های حیاتی مشکل داشته باشند، Build ممکن است برای ادامه تست مناسب نباشد.

رابطه Smoke Testing و BVT

             New Build
                 ↓
      Build Verification
                 ↓
        Critical Tests
                 ↓
          Pass / Fail

در عمل، این Critical Tests می‌توانند همان Test Caseهایی باشند که تیم آن‌ها را Smoke Test می‌نامد.

به همین دلیل در بسیاری از محیط‌های کاری ممکن است با عباراتی مانند Smoke Test و Build Verification Test مواجه شوید که برای هدفی بسیار مشابه استفاده شده‌اند.

آیا BVT دقیقاً همان Smoke Test است؟

نه لزوماً.

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

یک تیم ممکن است بگوید:

«بعد از هر Build، Smoke Test اجرا می‌کنیم.»

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

«بعد از Build، BVT اجرا می‌کنیم.»

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

چرا اصطلاح BVT استفاده می‌شود؟

نام BVT تأکید بیشتری روی Build دارد؛ یعنی سؤال اصلی این است:

آیا این Build از نظر حداقل قابلیت‌های ضروری، قابل قبول است؟

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

Build 101
   ↓
BVT
   ↓
PASS
   ↓
QA Testing

Build 102
   ↓
BVT
   ↓
FAIL
   ↓
Build Rejected

در این مدل، BVT مانند یک فیلتر اولیه برای Buildها عمل می‌کند.

BVT در CI/CD

در Pipelineهای مدرن، BVT می‌تواند به‌صورت Automated اجرا شود.

Code Commit
     ↓
Build
     ↓
Deploy
     ↓
BVT / Smoke Tests
     ↓
   PASS?
   ↙   ↘
 YES    NO
  ↓      ↓
Continue  Stop
Pipeline  Pipeline

در اینجا Testها می‌توانند سریع اجرا شوند تا Pipeline قبل از ورود به مراحل سنگین‌تر، وضعیت Build را بررسی کند.

تفاوت BVT و Smoke Testing را چگونه توضیح دهیم؟

Smoke Testing بیشتر روی نوع و هدف تست تأکید دارد:

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

BVT بیشتر روی Build و تصمیم درباره قابل‌قبول بودن آن برای ادامه فرآیند تأکید دارد:

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

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

جمع‌بندی BVT و Smoke Testing

BVT و Smoke Testing بسیار نزدیک هستند.

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

آیا Build جدید به اندازه کافی سالم است که تست‌های بعدی را روی آن شروع کنیم؟

اما تعریف دقیق، Scope و نام‌گذاری آن‌ها ممکن است از یک سازمان به سازمان دیگر متفاوت باشد. در پروژه‌های مدرن نیز BVT یا Smoke Test می‌تواند در CI/CD Pipeline قرار بگیرد و به‌عنوان یک Quality Gate اولیه عمل کند.

تفاوت Smoke Testing با تست‌های مشابه

Smoke Testing به‌تنهایی مفهوم پیچیده‌ای نیست؛ مشکل زمانی ایجاد می‌شود که بخواهیم آن را با تست‌هایی مانند Sanity، Regression، Retesting، Functional و Acceptance Testing مقایسه کنیم.

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

نوع تست	هدف اصلی	Scope معمول	زمان اجرا
Smoke Testing	بررسی آمادگی اولیه Build	نسبتاً گسترده و کم‌عمق	بعد از Build یا Deployment
Sanity Testing	بررسی هدفمند یک تغییر یا بخش خاص	محدود و متمرکز	معمولاً بعد از تغییر یا Fix
Regression Testing	اطمینان از اینکه تغییرات جدید قابلیت‌های قبلی را خراب نکرده‌اند	معمولاً گسترده	پس از تغییرات مختلف
Retesting	بررسی مجدد یک Defect مشخص پس از Fix	بسیار محدود	بعد از Fix
Functional Testing	بررسی عملکرد سیستم در برابر Functional Requirements	بسته به نیاز، از محدود تا گسترده	در مراحل مختلف تست
Acceptance Testing	بررسی قابل‌قبول بودن سیستم از دید Business یا Customer	بر اساس Acceptance Criteria و نیازهای کسب‌وکار	معمولاً نزدیک Release یا Acceptance

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

Smoke Testing در مقابل Sanity Testing

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

Smoke Testing

سؤال اصلی:

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

Application
   ↓
Login
   ↓
Search
   ↓
Cart
   ↓
Checkout

در Smoke Testing چند قابلیت یا مسیر حیاتی را به‌صورت سریع بررسی می‌کنیم.

Sanity Testing

در کاربرد رایج بسیاری از تیم‌های مدرن، سؤال اصلی این است:

آیا تغییر یا Fix مشخصی که انجام شده، درست کار می‌کند؟

مثلاً فرض کنید Developer یک Bug مربوط به Coupon را Fix کرده است. QA می‌تواند روی همان بخش و قسمت‌های مرتبط تمرکز کند:

Coupon
   ↓
Apply Coupon
   ↓
Discount Calculation
   ↓
Order Total

در این کاربرد، Scope Sanity Testing معمولاً محدودتر و متمرکزتر از Smoke Testing است.

یک نکته مهم درباره Smoke و Sanity

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

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

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

Smoke Testing در مقابل Regression Testing

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

Smoke Testing می‌پرسد:

آیا Build اصلاً ارزش ادامه تست را دارد؟

Regression Testing می‌پرسد:

آیا تغییرات جدید باعث خراب شدن قابلیت‌هایی که قبلاً کار می‌کردند نشده‌اند؟

فرض کنیم یک Application دارای ۱۰۰۰ Test Case Regression باشد. Smoke Test ممکن است فقط ۲۰ تست حیاتی داشته باشد.

New Build
   ↓
Smoke
   ↓
PASS
   ↓
Regression
   ↓
Check Existing Functionality

بنابراین Smoke معمولاً یک Gate اولیه است، در حالی که Regression Testing یک بررسی گسترده‌تر برای کشف Regressionهاست.

یک مثال

فرض کنیم تیم Payment را تغییر داده است.

Smoke Test ممکن است فقط بررسی کند:

آیا یک Payment موفق انجام می‌شود؟

اما Regression Testing ممکن است موارد زیر را نیز بررسی کند:

Payment با روش‌های مختلف
Refund
Failed Payment
Retry
Order Cancellation
Invoice
موجودی
Notification
سایر قابلیت‌هایی که ممکن است تحت تأثیر تغییر قرار گرفته باشند

بنابراین Smoke و Regression را نباید با یکدیگر یکی دانست.

Smoke Testing در مقابل Retesting

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

Retesting چیست؟

Retesting یعنی اجرای مجدد Test Caseای که قبلاً به دلیل یک Defect Fail شده بود، پس از اصلاح Defect.

مثلاً:

Test Case: Apply Coupon
       ↓
     FAIL
       ↓
   Bug ثبت شد
       ↓
 Developer Fix
       ↓
 اجرای مجدد همان Test Case
       ↓
     Retesting

در مقابل، Smoke Testing یک هدف متفاوت دارد و سلامت اولیه Build را بررسی می‌کند.

مثلاً بعد از دریافت Build جدید، QA چند قابلیت حیاتی را بررسی می‌کند:

Login
Search
Cart
Checkout
Payment

بنابراین:

Retesting → بررسی مجدد یک Defect مشخص

Smoke Testing → بررسی آمادگی اولیه Build

Smoke Testing در مقابل Functional Testing

Functional Testing یک حوزه بسیار گسترده‌تر است.

هدف Functional Testing این است که بررسی کند آیا Software مطابق Functional Requirements رفتار می‌کند یا خیر.

مثلاً برای Login می‌توان ده‌ها Test Case داشت:

Login موفق
Password اشتباه
Username اشتباه
فیلد خالی
Password Reset
Account Lock
Validation
Session
و سایر سناریوهای موردنیاز

اما Smoke Testing ممکن است فقط یک Test Case داشته باشد:

Login با Credential معتبر موفق می‌شود.

بنابراین Smoke Testing می‌تواند از Testهای Functional استفاده کند، اما Functional Testing بسیار گسترده‌تر از Smoke Testing است.

Smoke Testing در مقابل Acceptance Testing

Acceptance Testing از دیدگاه متفاوتی به سیستم نگاه می‌کند.

سؤال اصلی Acceptance Testing معمولاً این است:

آیا سیستم نیازها و معیارهای پذیرش موردنظر Business یا Customer را برآورده می‌کند؟

در حالی که Smoke Testing می‌پرسد:

آیا Build از نظر قابلیت‌های حیاتی، برای ادامه تست آماده است؟

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

Smoke: آیا کاربر می‌تواند Login کند و یک Order ایجاد کند؟

Acceptance: آیا فرآیند خرید مطابق نیازهای Business و Acceptance Criteriaهای تعریف‌شده است و شرایط لازم برای پذیرش محصول را دارد؟

بنابراین ممکن است یک سیستم Smoke Test را Pass کند اما هنوز Acceptance Criteriaهای کامل را برآورده نکرده باشد.

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

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

Smoke Testing

Login → PASS
Search → PASS
Cart → PASS
Checkout → PASS

هدف: آیا Build قابل تست است؟

Sanity Testing

Apply Coupon
→ Discount Calculation
→ Final Price

هدف: آیا تغییر مربوط به Coupon به‌درستی کار می‌کند؟

Retesting

فرض کنیم Bug زیر قبلاً ثبت شده بود:

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

بعد از Fix، همان Test Case دوباره اجرا می‌شود.

هدف: آیا Bug مشخص‌شده واقعاً Fix شده است؟

Regression Testing

بعد از تغییر Coupon، تیم بررسی می‌کند آیا این تغییر باعث خراب شدن بخش‌های دیگری شده است:

Coupon
 ↓
Cart
 ↓
Checkout
 ↓
Payment
 ↓
Order
 ↓
Invoice

هدف: آیا تغییر جدید باعث Regression نشده است؟

Acceptance Testing

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

آیا سیستم جدید شرایط موردنیاز برای ارائه قابلیت Coupon را برآورده می‌کند؟

هدف: آیا محصول از دید Business قابل پذیرش است؟

خلاصه تفاوت‌ها

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

Smoke: آیا Build قابل تست است؟
Sanity: آیا تغییر یا بخش مشخص موردنظر درست کار می‌کند؟
Retesting: آیا Defect مشخص Fix شده است؟
Regression: آیا تغییر جدید چیز دیگری را خراب نکرده است؟
Acceptance: آیا محصول نیاز Business یا Customer را برآورده می‌کند؟
Functional Testing: آیا قابلیت‌ها مطابق Functional Requirements رفتار می‌کنند؟

این تفکیک کمک می‌کند Smoke Testing را بیش از حد بزرگ نکنیم و هر Test Case را در جای مناسب خود قرار دهیم.

آیا Smoke Testing نوعی Regression Testing است؟

این سؤال یکی از ابهام‌های رایج در Software Testing است، زیرا در عمل ممکن است بعضی از Test Caseهایی که در Smoke Suite قرار می‌گیرند، از نظر کاربرد در Regression Testing نیز مورد استفاده قرار بگیرند.

اما از این موضوع نباید نتیجه گرفت که:

Smoke Testing = Regression Testing

این دو تست از نظر هدف، Scope و تصمیمی که از نتیجه آن‌ها گرفته می‌شود متفاوت هستند.

یک Test Case می‌تواند در هر دو Suite وجود داشته باشد

یک Test Case به‌خودی‌خود الزاماً «Smoke» یا «Regression» نیست. این نام‌گذاری بیشتر به نقش و هدف Test Case در فرآیند تست مربوط می‌شود.

برای مثال، Test Case زیر را در نظر بگیرید:

User can successfully Login

همین Test Case می‌تواند بخشی از Smoke Suite باشد و بعد از تغییرات سیستم در Regression Suite نیز اجرا شود.

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

هدف Smoke Testing چیست؟

Smoke Testing می‌خواهد به این سؤال پاسخ دهد:

آیا Build جدید به اندازه کافی سالم است که تست‌های بیشتری روی آن انجام دهیم؟

به همین دلیل Smoke Test معمولاً:

سریع اجرا می‌شود؛
تعداد Test Caseهای محدودی دارد؛
روی Critical Functionality تمرکز می‌کند؛
در ابتدای چرخه تست Build اجرا می‌شود.

هدف Regression Testing چیست؟

Regression Testing می‌خواهد بررسی کند:

آیا تغییرات جدید باعث ایجاد مشکل در قابلیت‌هایی شده‌اند که قبلاً درست کار می‌کردند؟

به همین دلیل Regression Suite معمولاً Scope گسترده‌تری دارد و می‌تواند قابلیت‌هایی را پوشش دهد که مستقیماً یا غیرمستقیم تحت تأثیر تغییرات قرار گرفته‌اند.

برای مثال، بعد از تغییر Payment Service ممکن است Regression Testing شامل مواردی مانند Payment، Refund، Order Cancellation، Invoice، Coupon، Cart، Order History و Notification باشد.

چرا Smoke Test می‌تواند یک Regression را پیدا کند؟

فرض کنید Developer تغییری در Authentication Service ایجاد کرده است. پس از ایجاد Build جدید، Smoke Test اجرا می‌شود:

Application → PASS
Login       → FAIL

Smoke Testing در اینجا یک مشکل را کشف کرده است. این مشکل ممکن است یک Regression باشد؛ اما این موضوع به معنی تبدیل شدن Smoke Testing به Regression Testing نیست.

به بیان ساده:

Smoke Testing می‌تواند یک Regression را آشکار کند، اما هدف اصلی آن Regression Testing نیست.

آیا Smoke Suite می‌تواند شامل Test Caseهای Regression باشد؟

بله. ممکن است یک Test Case هم در Smoke Suite و هم در Regression Suite وجود داشته باشد.

مثلاً:

Login Test Case
       ↓
 ┌─────┴─────┐
 ↓           ↓
Smoke     Regression

اما باید بین Test Case و Test Suite / Test Activity تفاوت قائل شد. حضور یک Test Case مشترک به معنی یکسان بودن هدف دو فعالیت نیست.

آیا Smoke Suite زیرمجموعه Regression Suite است؟

در بعضی پروژه‌ها ممکن است Smoke Test Caseها از میان Test Caseهای Regression انتخاب شده باشند و در نتیجه از نظر اجرایی بخشی از Regression Suite محسوب شوند.

اما این یک رابطه اجرایی است، نه یک تعریف مفهومی. نمی‌توان به‌صورت عمومی گفت:

Smoke Testing همیشه زیرمجموعه Regression Testing است.

معیار اصلی، هدف و نقش Test Suite است.

Smoke Testing و Regression Testing در CI/CD

در یک Pipeline مدرن ممکن است فرآیند به شکل زیر باشد:

Commit
  ↓
Build
  ↓
Unit Tests
  ↓
Deploy
  ↓
Smoke Tests
  ↓
   PASS?
  ↙   ↘
Yes    No
 ↓      ↓
Regression  Stop

در این مدل، Smoke Test می‌تواند نقش Quality Gate اولیه را داشته باشد. اگر Smoke Fail شود، اجرای Regression Suite ممکن است متوقف شود؛ اگر Smoke Pass شود، تست‌های گسترده‌تر می‌توانند ادامه پیدا کنند.

یک معیار کاربردی برای تشخیص Test Caseهای Smoke

برای هر Test Case موجود در Smoke Suite این سؤال را بپرسید:

اگر این Test Fail شود، آیا احتمال دارد تصمیم بگیریم ادامه تست Build را متوقف کنیم؟

اگر پاسخ معمولاً «بله» باشد، حضور Test Case در Smoke منطقی‌تر است. اگر پاسخ «خیر» باشد، بهتر است بررسی شود که آیا جای آن در Functional یا Regression Suite مناسب‌تر نیست.

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

بهترین روش این است که سؤال اصلی هر تست را به خاطر بسپارید:

Smoke Testing: آیا این Build قابل تست است؟
Regression Testing: آیا تغییرات جدید چیزی را که قبلاً کار می‌کرد خراب کرده‌اند؟

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

اشتباهات رایج در Smoke Testing

Smoke Testing در ظاهر ساده است، اما طراحی و اجرای نادرست آن می‌تواند باعث شود این تست بخش زیادی از ارزش خود را از دست بدهد؛ به‌خصوص زمانی که Smoke Suite به‌مرور زمان بدون بازبینی بزرگ‌تر شود.

۱. تبدیل Smoke Suite به یک Regression Suite کوچک

یکی از رایج‌ترین اشتباهات این است که هر Test Case مهم به Smoke Suite اضافه شود.

Smoke Suite
   ↓
10 Tests
   ↓
30 Tests
   ↓
80 Tests
   ↓
200 Tests

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

راهکار: Smoke Suite را به‌صورت دوره‌ای بازبینی کنید و برای هر Test Case بپرسید: اگر این تست Fail شود، آیا واقعاً باید ادامه تست Build متوقف شود؟

۲. قرار دادن قابلیت‌های غیرحیاتی در Smoke

Smoke باید بر Critical Path و قابلیت‌های حیاتی تمرکز کند. برای مثال، Payment معمولاً کاندید مناسبی برای Smoke است، اما قابلیت‌هایی مانند Change Profile Picture معمولاً چنین اولویتی ندارند.

۳. تمرکز بیش از حد روی UI

Smoke Testing الزاماً به معنی باز کردن صفحات و کلیک کردن روی آن‌ها نیست. در یک سیستم مدرن ممکن است Critical Flowها از طریق API یا Serviceهای حیاتی نیز بررسی شوند.

API Health
     ↓
Authentication
     ↓
Order API
     ↓
Payment API

بنابراین Smoke Test می‌تواند شامل UI Tests، API Tests، Service Checks یا برخی Integration Checks باشد؛ انتخاب روش به Architecture و هدف Smoke Suite بستگی دارد.

۴. اجرای Smoke روی Environment ناپایدار

گاهی Smoke Test Fail می‌شود، اما مشکل از Application نیست. برای مثال Database در دسترس نیست، یک Service Down است، Test Data حذف شده یا Configuration اشتباه است.

Smoke Test → FAIL

Application Bug    → NO
Environment Issue  → YES

بنابراین قبل از نسبت دادن Failure به Application، باید علت آن مشخص شود. اگر Smoke Suite دائماً به دلیل مشکلات Infrastructure شکست بخورد، اعتماد تیم به نتایج آن کاهش پیدا می‌کند.

۵. نادیده گرفتن Flaky Tests

Smoke Test باید تا حد امکان Reliable و قابل تکرار باشد. فرض کنید نتیجه یک تست در اجرای متوالی چنین باشد:

Run 1 → PASS
Run 2 → FAIL
Run 3 → PASS
Run 4 → PASS
Run 5 → FAIL

این Test احتمالاً Flaky است. وجود Flaky Test در Smoke Suite، به‌خصوص زمانی که Smoke نقش Quality Gate دارد، می‌تواند باعث ایجاد Failureهای کاذب و کاهش اعتماد تیم به این تست‌ها شود.

۶. وابستگی بیش از حد به Test Data

Smoke Test نباید تا حد امکان به داده‌هایی وابسته باشد که به‌صورت تصادفی توسط فرآیندهای دیگر تغییر یا حذف می‌شوند.

Test Data مربوط به Smoke بهتر است پایدار، قابل کنترل و قابل بازسازی باشد.

۷. نادیده گرفتن Failureهای Smoke

اگر Smoke Suite قرار است نقش Quality Gate داشته باشد، Failure آن باید بررسی شود. البته هر Failure الزاماً به معنی Bug در Application نیست و ممکن است مشکل Environment یا Test Data باشد؛ اما در هر صورت علت Failure باید مشخص شود.

۸. فرض اینکه Smoke Pass یعنی محصول بدون Bug است

Pass شدن Smoke Test فقط نشان می‌دهد Critical Flowهای انتخاب‌شده در بررسی اولیه موفق بوده‌اند.

Smoke Pass ≠ محصول بدون Bug

ممکن است صدها Bug در بخش‌هایی وجود داشته باشند که Smoke Suite اصلاً آن‌ها را بررسی نکرده است.

۹. انتخاب Test Caseها فقط بر اساس تعداد

نباید برای Smoke Suite یک عدد ثابت و جهانی تعیین کرد؛ مثلاً اینکه «Smoke باید دقیقاً ۲۰ تست داشته باشد».

Smoke Suite باید بر اساس عواملی مانند Criticality، Risk، Architecture، Business Flow، Release Frequency و Execution Time طراحی شود.

۱۰. عدم بازبینی Smoke Suite

Smoke Suite نباید یک مجموعه کاملاً ثابت باشد. با تغییر سیستم، Business، Architecture و Critical Pathها، Smoke Suite نیز ممکن است نیاز به تغییر داشته باشد.

Version 1
Login
Search
Cart
Payment

        ↓

Version 2
Login
Search
Cart
Subscription
Payment

اگر Subscription در نسخه جدید به یک قابلیت حیاتی تبدیل شده باشد، ممکن است لازم باشد در Smoke Suite نیز قرار بگیرد.

۱۱. اجرای Smoke بدون تعریف واضح Pass/Fail

قبل از اجرای Smoke باید مشخص باشد چه چیزی باعث Pass شدن Build می‌شود. برای مثال ممکن است تیم تصمیم بگیرد Failure در یک Critical Test باعث Block شدن Build شود، در حالی که Failure یک قابلیت غیرحیاتی فقط به‌صورت Warning ثبت شود.

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

۱۲. طولانی بودن بیش از حد Smoke Test

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

البته هیچ زمان استاندارد جهانی برای Smoke Test وجود ندارد؛ معیار اصلی این است که زمان اجرای آن با هدف و نقش آن در فرآیند Delivery سازگار باشد.

Checklist طراحی Smoke Suite مناسب

قبل از اضافه کردن یک Test Case به Smoke Suite، می‌توان این سؤالات را مطرح کرد:

آیا این قابلیت برای Business حیاتی است؟
آیا در Critical Path قرار دارد؟
آیا Failure آن می‌تواند ادامه تست را بی‌معنی کند؟
آیا Test قابل اعتماد و پایدار است؟
آیا Test سریع اجرا می‌شود؟
آیا Test Data آن قابل کنترل است؟
آیا اجرای آن ارزش بیشتری نسبت به هزینه نگهداری دارد؟
آیا Test دیگری همین هدف را بهتر پوشش می‌دهد؟

مهم‌ترین اصل در طراحی Smoke Test

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

Smoke Suite را با Test Caseهای زیاد بهتر نکنید؛ آن را با Test Caseهای درست بهتر کنید.

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

چگونه Smoke Test Case طراحی کنیم؟

طراحی Smoke Test Case فقط به این معنی نیست که چند Test Case مهم را از Test Suite انتخاب کنیم.

یک Smoke Suite خوب باید به‌صورت هدفمند طراحی شود تا بتواند در مدت کوتاهی مشخص کند:

آیا Build جدید برای ادامه تست آماده است یا خیر؟

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

مرحله ۱: Critical Business Flowها را شناسایی کنید

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

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

Login
   ↓
Search Product
   ↓
Product Details
   ↓
Add to Cart
   ↓
Checkout
   ↓
Payment

این مسیر احتمالاً یکی از مهم‌ترین Critical Pathهای سیستم است.

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

Registration
Subscription
Refund
Order Cancellation
Account Management

همه این موارد الزاماً وارد Smoke Suite نمی‌شوند. ابتدا باید Critical Business Flowها را شناسایی کنیم.

مرحله ۲: قابلیت‌هایی را پیدا کنید که Failure آن‌ها Build را عملاً غیرقابل تست می‌کند

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

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

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

پس Login کاندید بسیار خوبی برای Smoke است.

اما مثلاً Change Avatar اگر خراب باشد، احتمالاً بیشتر تست‌های سیستم همچنان قابل اجرا هستند. پس احتمالاً Smoke Candidate مناسبی نیست.

مرحله ۳: Test Caseهای High-Risk را شناسایی کنید

Criticality تنها معیار نیست. Risk نیز اهمیت زیادی دارد.

فرض کنید یک سیستم پرداخت دارید. Payment ممکن است:

Business Critical باشد؛
ریسک مالی داشته باشد؛
وابستگی‌های زیادی داشته باشد؛
در Release جدید تغییر کرده باشد.

در این شرایط Payment احتمالاً باید در Smoke Suite قرار بگیرد.

Business Criticality
        +
Technical Risk
        +
Change Impact
        ↓
Smoke Priority

هرچه این عوامل بالاتر باشند، احتمال انتخاب Test Case برای Smoke بیشتر می‌شود.

مرحله ۴: Happy Path را ابتدا انتخاب کنید

Smoke Testing معمولاً باید ابتدا Happy Pathهای اصلی را بررسی کند.

Login

Valid Username
      +
Valid Password
      ↓
Successful Login

Shopping

Select Product
      ↓
Add to Cart
      ↓
Checkout
      ↓
Successful Payment

در Smoke Testing لازم نیست ابتدا تمام حالت‌های Exception و Edge Case را بررسی کنیم. هدف، بررسی مسیر اصلی و حیاتی است.

مرحله ۵: Test Case را تا حد امکان ساده نگه دارید

Smoke Test Case نباید پیچیدگی غیرضروری داشته باشد.

مناسب:

Verify that a valid user can log in successfully.

اما اگر Test Case تبدیل شود به:

Login → Reset Password → Change Password → Logout
→ Login → Update Profile → Verify Session → ...

احتمالاً بیش از حد پیچیده شده است.

Smoke Test باید قابل فهم، سریع و پایدار باشد.

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

فرض کنید Smoke Test مربوط به Checkout است.

User
 ↓
Product
 ↓
Cart
 ↓
Address
 ↓
Payment

هرچه Dependency بیشتر شود، احتمال Failure ناشی از عوامل غیرمرتبط نیز افزایش می‌یابد.

بنابراین باید مشخص کنیم:

Test Data چیست؟
چه Serviceهایی لازم‌اند؟
چه Environmentهایی باید در دسترس باشند؟
آیا Dependency خارجی وجود دارد؟
آیا می‌توان Test را مستقل‌تر کرد؟

مرحله ۷: Expected Result را دقیق تعریف کنید

Smoke Test نباید فقط بگوید:

Login works.

باید مشخص شود موفقیت دقیقاً به چه معناست.

مثلاً:

After entering valid credentials, the user is authenticated and redirected to the Dashboard.

این موضوع مخصوصاً در Automated Smoke Testing اهمیت زیادی دارد. Automation باید بداند دقیقاً چه چیزی را Verify کند.

مرحله ۸: زمان اجرای Test را بررسی کنید

Smoke Suite باید سریع باشد.

فرض کنید دو Test داریم:

Test A

Login → Dashboard
Time: 10 sec

Test B

Login
→ Search
→ Product
→ Cart
→ Checkout
→ Payment
→ Email Verification
→ Report Validation

Time: 15 min

هر دو ممکن است ارزشمند باشند، اما Test B باید با دقت بیشتری بررسی شود که آیا واقعاً برای Smoke مناسب است یا نه.

گاهی می‌توان Test پیچیده را به چند Check ساده‌تر تقسیم کرد.

مرحله ۹: Test Caseهای Smoke را Prioritize کنید

همه Smoke Testها الزاماً اهمیت یکسانی ندارند.

می‌توان آن‌ها را مثلاً به سه سطح تقسیم کرد:

P0 — Critical

Failure آن‌ها می‌تواند Build را Block کند.

Application Launch
Login
Payment

P1 — High

مهم هستند، اما ممکن است همیشه باعث Block شدن کل Build نشوند.

Search
Product Details
Order History

P2 — Lower Priority

ممکن است در Smoke Suiteهای گسترده‌تر استفاده شوند.

Wishlist
Profile Update

این اولویت‌بندی باید متناسب با Business و Risk پروژه تعریف شود و یک استاندارد جهانی ثابت برای Smoke Testing نیست.

نمونه Smoke Test Suite برای فروشگاه اینترنتی

حالا تمام مراحل بالا را در یک مثال ترکیب کنیم.

ID	Smoke Test	Priority	زمان تقریبی
ST-01	Application Launch	P0	10s
ST-02	Valid User Login	P0	20s
ST-03	Product Search	P1	20s
ST-04	Product Details	P1	15s
ST-05	Add Product to Cart	P0	20s
ST-06	Checkout	P0	30s
ST-07	Successful Payment	P0	30s

این مجموعه می‌تواند در چند دقیقه اجرا شود و اطلاعات ارزشمندی درباره سلامت اولیه Build ارائه دهد.

یک نمونه Test Case واقعی

ST-02 — Successful Login

Objective:

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

Precondition:

یک User معتبر در سیستم وجود داشته باشد.

Steps:

Open Application
Enter valid Username
Enter valid Password
Click Login

Expected Result:

کاربر با موفقیت Authenticate شده و وارد Dashboard شود.

Priority: P0

Type: Smoke

آیا باید برای هر Test Case برچسب Smoke بزنیم؟

اگر از Test Management Tool استفاده می‌کنید، بهتر است Smoke Test Caseها به‌صورت مشخص Tag یا Label شوند.

Tags:
[Smoke]
[Critical]
[P0]

این کار باعث می‌شود بتوانیم به‌راحتی Smoke Suite را جدا کنیم.

All Test Cases
       ↓
Filter: Smoke
       ↓
Smoke Suite

در محیط‌های Automation نیز می‌توان همین مفهوم را با Tag، Marker یا Test Group پیاده‌سازی کرد.

Smoke Test Case چه تفاوتی با Test Case معمولی دارد؟

از نظر ساختار، الزاماً تفاوت بنیادی ندارد.

ID
Title
Preconditions
Steps
Test Data
Expected Result
Priority
Status

تفاوت اصلی در هدف و جایگاه Test Case در Test Strategy است.

یعنی یک Test Case معمولی می‌تواند برای Functional Testing نوشته شود و یک Test Case دیگر به‌عنوان Smoke انتخاب شود.

یک نکته مهم: Smoke را از روی Risk طراحی کنید، نه تعداد

فرض کنید یک سیستم ۵۰۰ قابلیت دارد.

قرار نیست Smoke Suite شامل ۵۰۰ Test Case باشد.

حتی ممکن است فقط ۱۵ تا ۳۰ Test Case بتوانند بخش مهمی از Critical Pathهای سیستم را پوشش دهند.

در مقابل، اگر یک سیستم بسیار پیچیده و Risk-sensitive باشد، ممکن است Smoke Suite بزرگ‌تر شود.

Smoke Test Suite باید Risk-Based باشد، نه Number-Based.

اشتباه رایج در طراحی

یک اشتباه متداول این است که تیم از Regression Suite شروع کند و بگوید:

از بین این ۱۰۰۰ تست، ۱۰۰ تای مهم‌تر را انتخاب می‌کنیم و اسمشان را Smoke می‌گذاریم.

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

بهتر است از Business Critical Pathها و Riskها شروع کنیم و بعد Test Caseهای مناسب را طراحی یا انتخاب کنیم.

Business Criticality
        ↓
Critical Paths
        ↓
Risk Analysis
        ↓
Smoke Scenarios
        ↓
Smoke Test Cases

Checklist طراحی Smoke Test Suite

Critical Business Flowها مشخص شده‌اند.
قابلیت‌های High-Risk شناسایی شده‌اند.
Happy Pathهای اصلی پوشش داده شده‌اند.
Test Caseها کوتاه و قابل اجرا هستند.
Expected Resultها مشخص هستند.
Test Data قابل کنترل است.
Dependencyهای غیرضروری حذف شده‌اند.
Test Caseها Priority دارند.
Smoke Suite بیش از حد بزرگ نشده است.
Testهای Flaky شناسایی و اصلاح شده‌اند.
معیار Pass/Fail مشخص است.
امکان Automation برای Testهای پایدار بررسی شده است.

اصل طلایی طراحی Smoke Test

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

Smoke Test Case را طوری انتخاب کنید که با کمترین تعداد تست، بیشترین اطلاعات را درباره سلامت Critical Pathهای Build به دست آورید.

Smoke Suite خوب، لزوماً Smoke Suite بزرگ نیست.

Smoke Suite خوب، Smoke Suite هدفمند است.

فرآیند اجرای Smoke Testing؛ از دریافت Build تا اعلام نتیجه

طراحی Smoke Suite یک مرحله است، اما اجرای درست آن مرحله دیگری است.

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

فرآیند کلی را می‌توان این‌گونه تصور کرد:

Build جدید
    ↓
Build Deployment
    ↓
Environment Check
    ↓
Smoke Testing
    ↓
PASS / FAIL
    ↓
تصمیم درباره ادامه تست

مرحله ۱: دریافت Build جدید

فرآیند معمولاً زمانی شروع می‌شود که Build جدید در اختیار QA قرار می‌گیرد.

مثلاً:

Build 2.8.1 برای تست روی QA Environment Deploy شد.

در این مرحله QA باید اطلاعات پایه Build را داشته باشد:

Build Version
Environment
Release/Change Information
Deployment Status
Known Issues
Test Data موردنیاز

این اطلاعات کمک می‌کنند QA بداند دقیقاً چه نسخه‌ای را تست می‌کند.

مرحله ۲: بررسی اولیه Environment

قبل از اجرای Smoke Test باید مطمئن شویم Environment در وضعیت قابل استفاده قرار دارد.

Application در دسترس است.
Database در دسترس است.
Serviceهای ضروری Running هستند.
Configuration صحیح است.
Test Data وجود دارد.
Dependencyهای ضروری در دسترس هستند.

اگر Environment از ابتدا مشکل داشته باشد، Failureهای Smoke ممکن است اصلاً مربوط به Build نباشند.

Environment Check با Smoke Test یکی نیست

این دو را نباید کاملاً یکی بدانیم.

Environment Check
       ↓
Is QA Environment available?

در مقابل:

Smoke Test
       ↓
Does the Application's critical functionality work?

ممکن است Environment کاملاً در دسترس باشد، اما Application مشکل داشته باشد.

مرحله ۳: اجرای Smoke Test

حالا Smoke Suite اجرا می‌شود.

ST-01 Application Launch
ST-02 Login
ST-03 Search
ST-04 Product
ST-05 Cart
ST-06 Checkout
ST-07 Payment

اگر تست‌ها Manual باشند، QA آن‌ها را اجرا می‌کند. اگر Automated باشند، می‌توانند از طریق Test Runner یا CI/CD Pipeline اجرا شوند.

مرحله ۴: ثبت نتیجه هر Test Case

نتیجه هر Test باید ثبت شود.

Test Case	Result
Application Launch	PASS
Login	PASS
Search	PASS
Product	PASS
Cart	PASS
Checkout	FAIL
Payment	Not Executed

در این مثال، چون Checkout Fail شده، ممکن است Payment اصلاً اجرا نشود. این موضوع باید در گزارش مشخص باشد.

مرحله ۵: بررسی Failure

هر Failure الزاماً به معنی Bug نیست.

QA باید ابتدا مشخص کند Failure از چه نوعی است.

Smoke Failure
      ↓
Investigate
      ↓
 ┌────┼─────┐
 ↓    ↓     ↓
Bug  Data  Environment

Application Bug

مثلاً API با خطای 500 پاسخ داده است.

Test Data Problem

مثلاً User موردنیاز وجود ندارد.

Environment Problem

مثلاً Database یا یک Service Down است.

Configuration Problem

مثلاً URL مربوط به Payment Service اشتباه تنظیم شده است.

مرحله ۶: ثبت Bug در صورت تأیید Defect

اگر مشخص شد Failure ناشی از Application است، باید Bug Report ایجاد شود.

Title:

Checkout returns HTTP 500 after placing an order

Environment: QA

Build: 2.8.1

Steps:

Login
Select a product
Add product to Cart
Open Checkout
Continue to Payment

Expected Result:

Checkout page should load successfully.

Actual Result:

HTTP 500 error is displayed.

Severity/Priority: بر اساس Impact و Business Risk تعیین می‌شود.

مرحله ۷: تصمیم درباره Build

بعد از بررسی Failure باید مشخص شود آیا Build قابل ادامه تست است یا خیر.

Login → FAIL
      ↓
Critical Functionality
      ↓
Build Blocked

اما اگر یک قابلیت غیرحیاتی Fail شود:

Wishlist → FAIL
      ↓
Non-Critical
      ↓
Risk Assessment
      ↓
Testing May Continue

پس نتیجه Smoke فقط یک عدد Pass/Fail نیست؛ به تصمیم Test Execution منجر می‌شود.

مرحله ۸: اعلام نتیجه

نتیجه Smoke باید به افراد مرتبط اطلاع داده شود.

Smoke Test Result — Build 2.8.1

Total: 20
Passed: 19
Failed: 1
Blocked: 0

Status: BUILD BLOCKED

Reason:
Checkout returns HTTP 500.

این گزارش می‌تواند در Test Management Tool، Issue Tracker، CI/CD Dashboard یا کانال ارتباطی تیم منتشر شود.

مرحله ۹: در صورت Fix، Smoke را دوباره اجرا کنیم

فرض کنیم Developer مشکل Checkout را اصلاح کرده است.

Build جدید ایجاد می‌شود:

Build 2.8.2

Build 2.8.2
     ↓
Smoke Test
     ↓
Checkout → PASS
     ↓
Other Critical Flows
     ↓
Smoke → PASS

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

آیا باید فقط Test شکست‌خورده را دوباره اجرا کنیم؟

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

اما Smoke Testing معمولاً با هدف بررسی سلامت کلی Build انجام می‌شود.

بنابراین پس از دریافت Build جدید، بهتر است Smoke Suite طبق Strategy تیم دوباره اجرا شود، نه اینکه صرفاً یک Test Case شکست‌خورده دوباره اجرا شود.

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

Smoke Testing می‌تواند چند مرحله داشته باشد

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

Level 1 — Basic Smoke

Application Launch
Login
Basic API Health

Level 2 — Critical Flow Smoke

Search
Cart
Checkout
Payment

Level 3 — Extended Smoke

Critical Integrations
Important Services
Additional Business Flows

این مدل می‌تواند در CI/CD مفید باشد، چون همه تست‌ها لازم نیست در یک مرحله اجرا شوند.

مثال کامل فرآیند

فرض کنیم Build جدید ساعت ۱۰:۰۰ صبح Deploy شده است.

10:02

QA Environment Check: PASS

10:05

Smoke Test شروع می‌شود.

10:07 — Login: PASS

10:08 — Search: PASS

10:09 — Cart: PASS

10:10 — Checkout: FAIL

10:12

QA بررسی می‌کند و مشخص می‌شود Payment Service در Environment Down است.

بنابراین:

Application Bug = No

Environment Issue = Yes

تیم Infrastructure مشکل را برطرف می‌کند.

10:20

پس از رفع مشکل Environment، Smoke Suite مجدداً طبق Strategy تیم اجرا می‌شود.

تمام Critical Flowها: PASS

10:25

Build: Ready for Further Testing

و سپس Regression و سایر تست‌ها آغاز می‌شوند.

این مثال نشان می‌دهد چرا تشخیص علت Failure به اندازه خود اجرای Smoke Test اهمیت دارد.

چه زمانی Smoke Testing را متوقف کنیم؟

اگر یک Failure بحرانی در ابتدای Smoke مشاهده شود، ادامه اجرای Test Caseهای وابسته ممکن است ارزش نداشته باشد.

مثلاً:

Login → FAIL

اگر تمام تست‌های بعدی نیاز به Login داشته باشند، اجرای آن‌ها منطقی نیست.

اما اگر Failure مربوط به یک قابلیت مستقل باشد، ممکن است ادامه Smoke امکان‌پذیر باشد.

بنابراین Dependency بین Test Caseها نیز در طراحی و اجرای Smoke اهمیت دارد.

خروجی نهایی Smoke Testing چیست؟

در پایان باید حداقل این اطلاعات مشخص باشد:

Build مورد آزمایش
Environment
زمان اجرای تست
تعداد Test Caseها
Passed
Failed
Blocked
Failureهای مهم
Bugهای ایجادشده
تصمیم نهایی درباره Build

مثلاً:

Smoke Test Report

Build: 2.8.2
Environment: QA

Total:   20
Passed:  20
Failed:   0
Blocked:  0

Status: READY FOR TESTING

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

Smoke Testing فقط یک فعالیت QA نیست.

در تیم‌های Agile و DevOps، نتیجه Smoke می‌تواند روی تصمیم کل تیم تأثیر بگذارد:

Smoke Result
     ↓
QA
     ↓
Development
     ↓
DevOps
     ↓
Release Decision

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

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

جمع‌بندی

فرآیند اجرای Smoke Testing را می‌توان در این مراحل خلاصه کرد:

Build → Environment Check → Smoke Execution → Failure Analysis → Bug/Issue → Build Decision → Re-test/Smoke Again → Further Testing

Smoke Testing نباید فقط مشخص کند «چه تستی Fail شده»؛ باید به تیم کمک کند تصمیم بگیرد «آیا ادامه تست این Build منطقی است یا خیر».

چگونه Smoke Testing را Automated کنیم؟

Automated Smoke Testing یکی از کاربردهای بسیار مناسب Test Automation است؛ زیرا Smoke Testها معمولاً تکراری، محدود، سریع و مبتنی بر Critical Flowهای مشخص هستند.

با این حال، Automated کردن Smoke Testing صرفاً به معنی تبدیل Test Caseهای دستی به Script نیست. باید ابتدا مشخص کنیم چه چیزی را Automated کنیم، در چه لایه‌ای تست کنیم و Automation را چگونه در فرآیند Build و Deployment قرار دهیم.

از کجا Automation را شروع کنیم؟

بهتر است ابتدا Smoke Suite دستی خود را بررسی کنیم.

فرض کنید Smoke Suite یک فروشگاه اینترنتی شامل این Testهاست:

Application Launch
Login
Product Search
Product Details
Add to Cart
Checkout
Payment

حالا هر Test Case را از نظر این معیارها بررسی می‌کنیم:

آیا تکرار زیادی دارد؟
آیا نتیجه آن قابل پیش‌بینی است؟
آیا Test Data قابل کنترل است؟
آیا قابلیت موردنظر نسبتاً پایدار است؟
آیا اجرای دستی آن زمان‌بر است؟
آیا Failure آن اهمیت زیادی دارد؟
آیا Automation آن هزینه نگهداری قابل قبولی دارد؟

هرچه پاسخ مثبت‌تر باشد، Test Case کاندید مناسب‌تری برای Automation است.

همه Smoke Testها را با UI اجرا نکنید

یکی از اشتباهات رایج این است که تیم تصور کند Automated Smoke Testing یعنی:

باز کردن Browser و کلیک کردن روی تمام مراحل.

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

بسته به Architecture سیستم، می‌توان Smoke Test را در لایه‌های مختلف اجرا کرد.

              Smoke Testing
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
      API           UI        Service
      Smoke        Smoke       Checks

API Smoke Testing

فرض کنید یک سیستم E-Commerce داریم.

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

می‌توان مستقیماً API را بررسی کرد:

POST /orders
      ↓
HTTP 201
      ↓
Order Created

در اینجا Smoke Test می‌تواند بررسی کند:

API در دسترس است؛
Authentication کار می‌کند؛
Request معتبر پذیرفته می‌شود؛
Response صحیح برمی‌گردد؛
داده مورد انتظار ایجاد می‌شود.

این تست معمولاً سریع‌تر و پایدارتر از یک UI Test معادل است.

UI Smoke Testing

با این حال، بعضی Critical Flowها بهتر است از طریق UI نیز بررسی شوند.

Open Website
     ↓
Login
     ↓
Search Product
     ↓
Add to Cart
     ↓
Checkout

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

اما بهتر است تعداد UI Smoke Testها بی‌دلیل زیاد نشود؛ زیرا UI Automation معمولاً نسبت به API Automation هزینه نگهداری بیشتری دارد.

یک رویکرد ترکیبی

در یک سیستم مدرن ممکن است Smoke Suite به شکل زیر طراحی شود:

                 Smoke Suite
                     │
        ┌────────────┼────────────┐
        ↓            ↓            ↓
    API Smoke     UI Smoke    Service Health
        │            │            │
    Fast Tests    Critical UI    Availability

برای مثال:

API

Authentication
Product API
Order API
Payment API

UI

Application Launch
Login
Critical Checkout Flow

Service

Service Availability
Dependency Health

این ترکیب می‌تواند نسبت به اتکا به UI Automation در تمام Smoke Suite، سریع‌تر و قابل‌اعتمادتر باشد.

Smoke Automation و Test Pyramid

در طراحی Automation بهتر است تعداد زیادی Test در لایه UI ایجاد نکنیم.

        UI Smoke
          /\
         /  \
        /    \
       API / Service
      /          \
     /            \
    ────────────────

یعنی برای بسیاری از بررسی‌های سریع و تکراری، API و Service-level Testing می‌تواند انتخاب مناسبی باشد و UI فقط برای Critical User Journeyهایی استفاده شود که واقعاً ارزش بررسی در سطح UI را دارند.

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

انتخاب Framework

انتخاب ابزار باید بعد از مشخص شدن نیازهای پروژه انجام شود.

برای UI Automation ممکن است تیم از ابزارهایی مانند:

Playwright
Selenium
Cypress

استفاده کند.

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

ابزار خوب، Smoke Suite بد را نجات نمی‌دهد.

اگر Test Caseهای اشتباه را Automated کنیم، فقط یک Smoke Suite اشتباه را سریع‌تر اجرا کرده‌ایم.

Smoke Test باید سریع باشد

یکی از معیارهای مهم Automated Smoke Testing، Execution Time است.

Smoke Suite A → 2 minutes
Smoke Suite B → 20 minutes
Smoke Suite C → 90 minutes

اگر هر سه Suite تعداد مشابهی از Critical Flowها را پوشش دهند، Suite A معمولاً برای Feedback اولیه مناسب‌تر است.

البته زمان مناسب به پروژه و Pipeline بستگی دارد و عدد ثابتی برای همه تیم‌ها وجود ندارد.

هدف اصلی:

Feedback سریع درباره سلامت Build

Test Data را مدیریت کنید

Automation بدون Test Data مناسب می‌تواند بسیار شکننده شود.

مثلاً Smoke Test Login نیازمند User خاصی است.

اگر Password آن User هر چند روز تغییر کند، Test ممکن است بدون وجود Bug در Application Fail شود.

راهکارهای مختلفی وجود دارد:

Dedicated Test User
Test Data Management
API-based Data Setup
Database Seeding
ایجاد Data قبل از Test
استفاده از Mock یا Stub در شرایط مناسب

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

از Hard-Coded Data بیش از حد استفاده نکنید

مثلاً این رویکرد شکننده است:

username = testuser123
password = Test@123
product = Laptop123

اگر Product حذف شود، Smoke Test Fail می‌شود.

در بسیاری از پروژه‌ها بهتر است Test Data قبل از اجرا ایجاد یا بازیابی شود.

Create Test User
       ↓
Create Test Product
       ↓
Run Smoke Test
       ↓
Cleanup

البته روش مناسب به Architecture و محدودیت‌های پروژه بستگی دارد.

Smoke Testها باید قابل تکرار باشند

اگر یک Test یک بار Pass و بار دیگر بدون تغییر در Application Fail شود، نمی‌توان به آن اعتماد کرد.

Run 1 → PASS
Run 2 → PASS
Run 3 → FAIL
Run 4 → PASS

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

در Smoke Testing این مشکل جدی‌تر است، زیرا Smoke ممکن است Quality Gate باشد.

Flaky Test را با Retry پنهان نکنید

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

اگر Smoke Fail شد، دوباره اجرا کن.

Run 1 → FAIL
Run 2 → PASS

و Pipeline را موفق اعلام کنیم.

گاهی Retry می‌تواند برای بعضی Failureهای موقتی مفید باشد، اما نباید جایگزین حل مشکل Flakiness شود.

اگر Test دائماً ناپایدار است، باید علت آن مشخص شود.

Smoke Testing در CI/CD

حالا Automation واقعاً ارزش خود را نشان می‌دهد.

Developer Commit
       ↓
      Build
       ↓
   Unit Tests
       ↓
    Deploy
       ↓
 Automated Smoke
       ↓
    ┌───────┐
    │ PASS? │
    └───┬───┘
      ↙   ↘
    YES    NO
     ↓      ↓
 Further   Stop /
 Testing   Investigate

در این حالت، Smoke Test به‌عنوان یک Automated Quality Gate عمل می‌کند.

Smoke Test چه زمانی در Pipeline اجرا شود؟

این موضوع به ساختار Pipeline بستگی دارد.

ممکن است Smoke بعد از:

Build
Deployment به Test Environment
Deployment به Staging
ایجاد یک Release Candidate

اجرا شود.

Code
 ↓
Build
 ↓
Deploy to QA
 ↓
Smoke
 ↓
Integration
 ↓
Regression

یا در Pipeline دیگری:

Build
 ↓
Unit
 ↓
Deploy
 ↓
API Smoke
 ↓
UI Smoke
 ↓
Release

بنابراین نباید یک ترتیب واحد را برای تمام پروژه‌ها اجباری بدانیم.

گزارش نتیجه Automation

Automated Smoke Test باید نتیجه قابل‌فهمی تولید کند.

Smoke Test Report

Build: 2.8.2
Environment: QA

Total:   25
Passed:  24
Failed:   1

Status: BLOCKED

Failed:
ST-17 Payment API
Expected: HTTP 200
Actual: HTTP 500

این گزارش باید به‌راحتی برای QA، Developer و DevOps قابل استفاده باشد.

Smoke Automation نباید تبدیل به یک پروژه جداگانه شود

گاهی تیم برای Automated کردن ۲۰ Smoke Test، یک Framework بسیار پیچیده ایجاد می‌کند که نگهداری آن خودش تبدیل به مشکل می‌شود.

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

پیچیده‌ترین Framework ممکن را بسازیم.

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

Smoke Testing در Agile و DevOps چه جایگاهی دارد؟

در تیم‌های سنتی، Smoke Testing ممکن است بعد از تحویل یک Build به تیم QA انجام شود. اما در محیط‌های Agile و DevOps، Build، Release و Deployment معمولاً با دفعات بیشتری انجام می‌شوند. بنابراین Smoke Testing می‌تواند از یک فعالیت دستی محدود به یک Quality Gate خودکار در فرآیند تحویل نرم‌افزار تبدیل شود.

Smoke Testing در Agile

در Agile، توسعه نرم‌افزار معمولاً در Iteration یا Sprintهای کوتاه انجام می‌شود و در طول یک Sprint ممکن است چندین Build برای تست ایجاد شود. بنابراین Smoke Testing می‌تواند برای Buildهایی که در اختیار QA قرار می‌گیرند، به‌عنوان یک بررسی سریع اولیه اجرا شود.

Development
     ↓
New Build
     ↓
Deploy to Test Environment
     ↓
Smoke Testing
     ↓
Further Testing

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

آیا Smoke فقط در پایان Sprint انجام می‌شود؟

خیر. Smoke Testing الزاماً به پایان Sprint وابسته نیست. اگر در طول یک Sprint چند Build برای QA ارسال شود، می‌توان برای هر Build مناسب، Smoke Test اجرا کرد.

Sprint 12
│
├── Build 101 → Smoke → PASS
│
├── Build 102 → Smoke → PASS
│
├── Build 103 → Smoke → FAIL
│
└── Build 104 → Smoke → PASS

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

Smoke Testing در DevOps

در DevOps، یکی از اهداف مهم کاهش فاصله بین Code، Build، Test، Deploy و Feedback است. Smoke Testing می‌تواند در همین چرخه قرار گیرد و پس از Deployment، سلامت اولیه Build را بررسی کند.

Developer Commit
       ↓
      Build
       ↓
 Automated Tests
       ↓
    Deployment
       ↓
 Automated Smoke
       ↓
   ┌───────┐
   │ PASS? │
   └───┬───┘
    YES│NO
       │
       ├──────────────┐
       ↓              ↓
 Continue         Stop / Alert

در این مدل، Smoke Test می‌تواند یکی از اولین Quality Gateهای بعد از Deployment باشد.

Smoke Test به‌عنوان Quality Gate

یکی از مهم‌ترین کاربردهای Smoke Testing در DevOps، استفاده از آن به‌عنوان Quality Gate است. فرض کنید Pipeline قصد دارد یک Build را به محیط بعدی منتقل کند. قبل از ادامه، Smoke Suite اجرا می‌شود.

Smoke = PASS
        ↓
Pipeline Continues

Smoke = FAIL
        ↓
Pipeline Stops / Deployment Blocked

در نتیجه، Smoke Testing از یک Test Activity ساده به بخشی از Release Decision تبدیل می‌شود. البته اینکه Failure باعث توقف کامل Pipeline شود یا فقط یک هشدار ایجاد کند، باید بر اساس Risk و سیاست تیم مشخص شود.

Continuous Testing و Smoke Testing

در DevOps مفهوم Continuous Testing اهمیت زیادی دارد. به‌جای اینکه تست فقط در انتهای فرآیند انجام شود، Testها می‌توانند در مراحل مختلف Pipeline اجرا شوند.

Code
 ↓
Unit Tests
 ↓
Build
 ↓
API Tests
 ↓
Deploy
 ↓
Smoke Tests
 ↓
Integration Tests
 ↓
Regression Tests
 ↓
Release

Smoke Testing در این مدل یکی از لایه‌های Feedback سریع است. البته ترتیب دقیق Testها به Architecture، Pipeline و Test Strategy هر پروژه بستگی دارد و این ترتیب یک الگوی اجباری و جهانی نیست.

آیا باید بعد از هر Commit Smoke Test اجرا شود؟

الزاماً نه. تصمیم درباره زمان اجرای Smoke به سرعت Pipeline، هزینه اجرای تست‌ها، نوع تست‌ها و معماری پروژه بستگی دارد.

اگر Smoke Suite بسیار سریع باشد، ممکن است اجرای آن در هر تغییر منطقی باشد:

Commit
 ↓
Build
 ↓
2-minute Smoke

اما اگر Smoke Suite شامل تعداد زیادی UI Test باشد و مثلاً ۴۵ دقیقه زمان ببرد، اجرای آن بعد از هر Commit ممکن است هزینه و زمان Pipeline را بیش از حد افزایش دهد.

در چنین شرایطی می‌توان Smoke را بعد از مراحل مشخصی اجرا کرد:

Commit
 ↓
Unit Tests
 ↓
Build
 ↓
Deploy
 ↓
Smoke

همچنین می‌توان Strategy متفاوتی برای Branchها، Pull Requestها و Buildهای قابل Deploy تعریف کرد.

Smoke Testing در Branchهای مختلف

در یک Workflow معمول Git، ممکن است Test Strategy برای Branchهای مختلف متفاوت باشد. برای مثال:

Feature Branch
      ↓
Unit Tests
      ↓
Pull Request
      ↓
Integration
      ↓
Main Branch
      ↓
Deploy
      ↓
Smoke

در این مدل، Smoke ممکن است بیشتر روی Buildهایی اجرا شود که برای Deployment یا تست‌های گسترده‌تر آماده هستند. با این حال، Strategy واقعی باید بر اساس Workflow تیم تعریف شود.

Smoke و Deployment

Smoke Testing می‌تواند بعد از Deployment در محیط‌های مختلف اجرا شود. برای مثال:

Build
  ↓
Deploy to QA
  ↓
Smoke

Build
  ↓
Deploy to Staging
  ↓
Smoke

در بعضی معماری‌ها حتی می‌توان بعد از Production Deployment نیز مجموعه‌ای محدود از Production Smoke Tests یا Post-Deployment Checks اجرا کرد.

Application در دسترس است.
Login کار می‌کند.
یک API حیاتی پاسخ مناسب می‌دهد.
مسیر اصلی Business قابل استفاده است.

Production Smoke Testing

اجرای Smoke Test روی Production حساس‌تر از محیط‌های Test و Staging است. Testهایی که ممکن است داده واقعی ایجاد یا تغییر دهند، نباید بدون Strategy مناسب روی Production اجرا شوند.

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

Test Account
Test Product
Mock Payment
Synthetic Transaction
Safe Test Data

هدف این است که تست بتواند سلامت سرویس را بررسی کند، بدون اینکه باعث ایجاد اثر واقعی و ناخواسته در Production شود.

Smoke Testing و Microservices

در معماری Microservices، Smoke Testing می‌تواند اهمیت بیشتری پیدا کند؛ زیرا یک سیستم ممکن است از چندین Service تشکیل شده باشد که به‌صورت مستقل توسعه و Deploy می‌شوند.

                Web App
                   │
        ┌──────────┼──────────┐
        ↓          ↓          ↓
   Auth Service  Product    Order
                   │          │
                   └────┬─────┘
                        ↓
                  Payment Service

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

Service در دسترس است.
API اصلی پاسخ مناسب می‌دهد.
Authentication کار می‌کند.
Serviceهای حیاتی می‌توانند با یکدیگر ارتباط برقرار کنند.
Critical User Journey همچنان قابل اجرا است.

بنابراین در معماری Microservices، علاوه بر UI Smoke، API و Service-level Smoke Checks نیز می‌توانند نقش مهمی داشته باشند.

آیا Smoke Testing جایگزین سایر تست‌ها می‌شود؟

به هیچ وجه. Smoke Testing فقط یکی از لایه‌های Test Strategy است و نمی‌تواند جایگزین تست‌های دیگر شود.

               Testing Strategy
                     │
      ┌──────────────┼──────────────┐
      ↓              ↓              ↓
    Unit           Smoke        Regression
      ↓              ↓              ↓
 Integration     Critical       Broad Coverage
      ↓            Flows
 Performance
 Security
 Accessibility
 ...

Functional Testing
Regression Testing
Integration Testing
Performance Testing
Security Testing
Accessibility Testing

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

Smoke Testing در یک تیم Agile چه کسی انجام می‌دهد؟

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

Manual QA
Automation Engineer
QA Engineer
SDET
ترکیبی از نقش‌های مختلف تیم QA

در تیم‌های مدرن‌تر، بخش زیادی از Smoke Suite می‌تواند Automated باشد و به CI/CD متصل شود؛ در حالی که QA همچنان مسئول طراحی، بازبینی و تحلیل نتایج است.

نقش QA در Automated Smoke

Automated بودن Smoke به معنی حذف نقش QA نیست. QA همچنان باید بررسی کند:

آیا Smoke Suite واقعاً Critical Pathهای سیستم را پوشش می‌دهد؟

ممکن است Automation Engineer تعداد زیادی Test نوشته باشد، اما مهم‌ترین Business Flow سیستم اصلاً در Smoke Suite وجود نداشته باشد.

بنابراین مسئولیت QA فقط اجرای تست نیست و می‌تواند شامل موارد زیر باشد:

انتخاب سناریو
Risk Analysis
طراحی Test
بررسی Coverage
تحلیل Failure
بازبینی و نگهداری Smoke Strategy

Smoke Testing و Shift-Left

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

Smoke Testing معمولاً بعد از Build یا Deployment انجام می‌شود؛ بنابراین به‌تنهایی یک تکنیک Shift-Left محسوب نمی‌شود. با این حال، قرار دادن Smoke در یک فرآیند سریع CI/CD می‌تواند Feedback را بسیار زودتر در اختیار تیم قرار دهد.

Earlier Feedback
       ↓
Faster Detection
       ↓
Lower Cost of Fix

به همین دلیل، Automated Smoke Testing می‌تواند با فلسفه DevOps، Continuous Testing و Feedback سریع هم‌راستا باشد.

یک Pipeline پیشنهادی

برای یک Web Application مدرن می‌توان Pipelineی مانند نمونه زیر داشت:

Developer Commit
       ↓
Static Analysis
       ↓
Unit Tests
       ↓
Build
       ↓
Deploy to QA
       ↓
API Smoke
       ↓
UI Smoke
       ↓
Integration Tests
       ↓
Regression
       ↓
Deploy Staging
       ↓
Production

این فقط یک نمونه معماری Pipeline است و در پروژه واقعی ممکن است ترتیب یا اجزای Pipeline بر اساس Architecture، Risk و نیازهای تیم تغییر کند.

مهم‌ترین نکته در Agile و DevOps

در محیط‌های Agile و DevOps، ارزش Smoke Testing فقط به خود Testها محدود نمی‌شود؛ بلکه سرعت Feedback و کیفیت تصمیم‌گیری اهمیت زیادی دارد.

یک Smoke Test خوب باید بتواند خیلی سریع به تیم بگوید آیا این Build ارزش ادامه تست و حرکت به مرحله بعد را دارد یا خیر.

به همین دلیل Smoke Testing معمولاً ترکیب مناسبی با Automation و CI/CD ایجاد می‌کند.

جمع‌بندی Smoke Testing در Agile و DevOps

Smoke Testing می‌تواند بعد از هر Build مهم اجرا شود.
الزاماً نباید فقط در پایان Sprint انجام شود.
می‌تواند بخشی از CI/CD Pipeline باشد.
می‌تواند به‌عنوان Quality Gate عمل کند.
می‌تواند قبل از تست‌های گسترده‌تر مانند Regression اجرا شود.
در Microservices، API و Service Smoke اهمیت زیادی دارند.
می‌توان Smoke Test را بعد از Production Deployment نیز با احتیاط اجرا کرد.
Smoke Testing جایگزین سایر Test Types نیست.
Automated بودن Smoke همچنان به طراحی، بازبینی و نظارت QA نیاز دارد.

در DevOps، Smoke Testing می‌تواند از یک بررسی ساده Build به یک Quality Gate خودکار تبدیل شود که از عبور Buildهای ناسالم به مراحل بعدی جلوگیری می‌کند.

Smoke Testing در برابر Sanity Testing در برابر Regression Testing

Smoke، Sanity و Regression از اصطلاحاتی هستند که حتی بین افراد فعال در QA نیز گاهی با یکدیگر اشتباه گرفته می‌شوند. یکی از دلایل این سردرگمی این است که این تست‌ها می‌توانند Test Caseهای مشترک داشته باشند و در بعضی پروژه‌ها نیز اصطلاحات با تعاریف متفاوتی استفاده شوند.

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

مقایسه کلی Smoke، Sanity و Regression

ویژگی	Smoke Testing	Sanity Testing	Regression Testing
هدف اصلی	بررسی سلامت اولیه Build	بررسی هدفمند Change یا Fix	بررسی اثرات ناخواسته تغییرات
Scope	نسبتاً گسترده اما کم‌عمق	محدود و متمرکز	گسترده
تعداد تست	کم	کم تا متوسط	متوسط تا بسیار زیاد
سرعت	سریع	سریع	معمولاً طولانی‌تر
زمان اجرا	معمولاً بعد از Build یا Deployment	معمولاً بعد از Change یا Fix	بعد از تغییرات مهم
تمرکز	Critical Functionality	Changed یا Related Area	Existing Functionality
Automation	بسیار مناسب	مناسب	بسیار مناسب
نتیجه مهم	آیا Build قابل تست است؟	آیا Change موردنظر درست به نظر می‌رسد؟	آیا چیزی در اثر Change خراب شده است؟

Smoke Testing

سؤال اصلی Smoke این است:

آیا Build جدید به اندازه کافی سالم است که تست‌های بیشتری را روی آن انجام دهیم؟

فرض کنید Build جدید یک فروشگاه اینترنتی دریافت کرده‌ایم. QA ابتدا چند مسیر حیاتی را بررسی می‌کند:

Application
   ↓
Login
   ↓
Product
   ↓
Cart
   ↓
Checkout
   ↓
Payment

اگر این مسیرهای حیاتی در سطح اولیه کار کنند، می‌توان تست‌های گسترده‌تر را آغاز کرد.

ویژگی اصلی Smoke: Breadth over Depth

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

Sanity Testing

در کاربرد رایج بسیاری از تیم‌های QA، Sanity Testing بعد از یک تغییر محدود یا Bug Fix انجام می‌شود و روی همان Change و بخش‌های مستقیماً مرتبط تمرکز دارد.

برای مثال، فرض کنید Developer منطق Coupon را اصلاح کرده است. QA می‌تواند ابتدا بخش مرتبط را بررسی کند:

Coupon
   ↓
Apply Coupon
   ↓
Discount Calculation
   ↓
Final Price

سؤال اصلی در این سناریو این است:

آیا تغییر موردنظر به‌درستی کار می‌کند؟

اما یک نکته مهم وجود دارد: تعریف Sanity در منابع مختلف یکسان نیست. در واژه‌نامه ISTQB، Sanity Test به‌عنوان Synonym برای Smoke Test ذکر شده است.

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

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

Regression Testing

سؤال اصلی Regression این است:

آیا تغییرات جدید باعث خراب شدن قابلیت‌هایی شده‌اند که قبلاً درست کار می‌کردند؟

فرض کنید Payment Service تغییر کرده است. Regression می‌تواند علاوه بر Payment، بخش‌هایی مانند موارد زیر را نیز بررسی کند:

Payment
Refund
Order
Coupon
Cart
Invoice
Notification
Order History

هدف فقط بررسی خود Payment نیست؛ بلکه پیدا کردن اثرات جانبی Change روی قابلیت‌های موجود نیز اهمیت دارد.

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

فرض کنید در یک فروشگاه اینترنتی، Developer منطق Discount را تغییر داده است.

Smoke

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

Login
 ↓
Product
 ↓
Cart
 ↓
Checkout
 ↓
Payment

سؤال: آیا Build جدید در سطح کلی قابل تست است؟

Sanity

روی تغییر جدید تمرکز می‌کند:

Coupon
 ↓
Discount Rule
 ↓
Final Price

سؤال: آیا تغییر Discount به‌درستی کار می‌کند؟

Regression

اثر تغییر را در سایر قسمت‌ها بررسی می‌کند:

Coupon
Cart
Checkout
Order
Invoice
Refund
Reports

سؤال: آیا تغییر Discount باعث خراب شدن بخش‌های دیگری شده است؟

تفاوت Scope

تفاوت Scope این سه Test Type را می‌توان به‌صورت یک مدل مفهومی در نظر گرفت:

             Regression
    ┌─────────────────────────┐
    │                         │
    │      Smoke              │
    │    ┌───────────┐        │
    │    │ Critical  │        │
    │    │  Flows    │        │
    │    └───────────┘        │
    │                         │
    │      Sanity             │
    │       ┌───────┐         │
    │       │Change │         │
    │       └───────┘         │
    │                         │
    └─────────────────────────┘

این تصویر فقط یک مدل مفهومی است و نباید به‌عنوان یک رابطه رسمی و ثابت بین این سه Test Type در همه پروژه‌ها در نظر گرفته شود.

تفاوت در سؤال اصلی

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

Smoke: آیا Build قابل تست است؟
Sanity: آیا تغییر مشخص به‌درستی کار می‌کند؟
Regression: آیا تغییر جدید چیزی را که قبلاً درست بود خراب کرده است؟

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

بله. یک Test Case ممکن است در Smoke، Sanity و Regression استفاده شود؛ اما Context و هدف اجرای آن متفاوت خواهد بود.

برای مثال:

Verify successful user login.

در Smoke برای بررسی Critical Login Flow
در Sanity برای بررسی Fix مربوط به Login
در Regression برای بررسی سلامت Authentication بعد از تغییرات مرتبط

بنابراین نباید تصور کنیم Test Caseها همیشه به یک Test Type خاص تعلق دارند.

تفاوت در زمان اجرا

یک Workflow رایج ممکن است به شکل زیر باشد:

New Build
   ↓
Smoke
   ↓
PASS
   ↓
Sanity / Functional Checks
   ↓
Regression

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

تفاوت در Automation

هر سه Test Type می‌توانند به‌صورت Manual یا Automated اجرا شوند.

Smoke Automation: معمولاً بسیار مناسب است، چون تست‌ها تکراری، سریع و Critical هستند.
Sanity Automation: برای Changeها و Fixهای مشخص می‌تواند مفید باشد.
Regression Automation: ارزش زیادی دارد، زیرا Regression Suite معمولاً بزرگ و تکراری است.

یک اشتباه مهم درباره Manual و Automated

نباید بگوییم:

Smoke همیشه Manual است.
Regression همیشه Automated است.
Sanity همیشه Manual است.

هیچ‌کدام از این جملات به‌صورت عمومی درست نیستند. Manual و Automated یک Dimension متفاوت از Smoke، Sanity و Regression هستند.

             Test Purpose
                  │
       ┌──────────┼──────────┐
       ↓          ↓          ↓
     Smoke      Sanity    Regression
       │          │          │
       └──────────┼──────────┘
                  ↓
            Execution Mode
             /          \
          Manual      Automated

جدول تصمیم‌گیری سریع

سؤال	احتمالاً چه تستی؟
آیا Build اصلاً قابل تست است؟	Smoke
آیا Critical Flowها سالم هستند؟	Smoke
آیا Fix مشخص درست شده است؟	Sanity*
آیا تغییر محدود رفتار مورد انتظار را دارد؟	Sanity*
آیا تغییر جدید چیز دیگری را خراب کرده است؟	Regression
آیا قابلیت‌های قبلی همچنان سالم هستند؟	Regression

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

نکته مهم برای QA Engineer

در مصاحبه‌های شغلی ممکن است از شما پرسیده شود:

What is the difference between Smoke Testing and Sanity Testing?

پاسخ بیش از حد ساده مانند «Smoke broad است و Sanity narrow» ممکن است کافی نباشد.

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

Smoke Testing is generally used as a broad, shallow check of critical functionality to determine whether a build is stable enough for further testing. In many teams, Sanity Testing refers to a focused check around a specific change or fix. However, terminology varies, and ISTQB lists Sanity Test as a synonym for Smoke Test.

این پاسخ هم کاربرد رایج صنعتی را بیان می‌کند و هم اختلاف Terminology را نادیده نمی‌گیرد.

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

اگر تیم شما از هر سه اصطلاح استفاده می‌کند، بهتر است در Test Strategy تعریف داخلی مشخصی برای آن‌ها داشته باشید. برای مثال:

Smoke: Critical Build Verification
Sanity: Focused Change Verification
Regression: Broad Verification of Existing Functionality

این کار از اختلاف برداشت میان QA، Developer و Product Team جلوگیری می‌کند.

جمع‌بندی Smoke، Sanity و Regression

Smoke، Sanity و Regression را نباید صرفاً بر اساس نام آن‌ها از هم تشخیص داد. بهتر است همیشه هدف، Scope، زمان اجرا و تصمیم مورد انتظار را بررسی کنیم.

SMOKE
"Can we test this build?"
        ↓
Critical & Broad

SANITY
"Does this specific change make sense?"
        ↓
Focused & Narrow

REGRESSION
"Did the change break existing functionality?"
        ↓
Broad & Deep

نکته مهم: تعریف Smoke و Regression نسبتاً رایج‌تر و پایدارتر است، اما درباره Sanity باید همیشه Context و Definition تیم را در نظر گرفت.

مزایا و محدودیت‌های Smoke Testing

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

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

مزایای Smoke Testing

۱. شناسایی سریع مشکلات بحرانی

مهم‌ترین مزیت Smoke Testing، Feedback سریع است. به جای اینکه تیم QA ابتدا صدها Test Case را اجرا کند، چند Critical Flow بررسی می‌شوند.

Build
 ↓
Smoke
 ↓
Login → FAIL

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

۲. جلوگیری از اتلاف زمان QA

فرض کنید یک Regression Suite شامل 1000 Test Case باشد. اگر Build از ابتدا مشکل جدی داشته باشد، اجرای این تست‌ها می‌تواند بخش زیادی از زمان تیم را هدر دهد.

1000 Tests
    ↓
Smoke
    ↓
Build Healthy?
   ↙     ↘
 NO       YES
 ↓         ↓
Stop    1000 Tests

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

۳. کاهش Feedback Time

در فرآیندهای Agile و DevOps، هرچه فاصله بین ایجاد مشکل و شناسایی آن کمتر باشد، تیم معمولاً می‌تواند سریع‌تر نسبت به آن واکنش نشان دهد.

Developer Change
       ↓
Build
       ↓
Smoke
       ↓
Failure Detected
       ↓
Developer Feedback

۴. مناسب برای Automation

Smoke Test Caseها معمولاً ویژگی‌هایی دارند که آن‌ها را برای Automation مناسب می‌کند:

تکراری هستند.
Expected Result مشخصی دارند.
Critical هستند.
معمولاً زیاد اجرا می‌شوند.
می‌توانند سریع اجرا شوند.

به همین دلیل Smoke Testing یکی از گزینه‌های مناسب برای قرار گرفتن در CI/CD Pipeline است.

۵. کمک به تصمیم‌گیری درباره Build

Smoke Test فقط یک Test Execution نیست. نتیجه آن می‌تواند به یک تصمیم درباره ادامه یا توقف تست منجر شود.

Smoke Result
     ↓
 ┌───┴────┐
 ↓        ↓
PASS     FAIL
 ↓        ↓
Continue  Investigate
Testing   Build

۶. کاهش هزینه تست

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

Smoke می‌تواند با جلوگیری از اجرای زودهنگام Test Suiteهای سنگین، در مصرف موارد زیر صرفه‌جویی کند:

زمان QA
منابع Automation
CI/CD Resources
زمان Developer

۷. ایجاد یک استاندارد اولیه برای Build

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

Build زمانی Ready for Testing است که Critical Smoke Suite را Pass کند.

البته معیار دقیق Ready for Testing باید متناسب با پروژه و Test Strategy تیم تعریف شود.

۸. مناسب برای Releaseهای مکرر

در محیط‌هایی که Deployment زیاد انجام می‌شود، اجرای Manual تست‌های گسترده برای هر Build عملی نیست. اما یک Automated Smoke Suite کوچک می‌تواند بعد از Deployment اجرا شود.

Deploy
  ↓
Automated Smoke
  ↓
2–5 min
  ↓
PASS / FAIL

در چنین شرایطی Smoke می‌تواند ارزش زیادی برای Feedback سریع ایجاد کند.

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

۱. پوشش تست محدود است

Smoke فقط بخشی از سیستم را بررسی می‌کند. فرض کنید Smoke Suite شامل ۲۰ Test Case باشد. Pass شدن هر ۲۰ تست به این معنی نیست که سیستم بدون Bug است.

ممکن است صدها قابلیت دیگر اصلاً بررسی نشده باشند.

۲. Bugهای عمیق را پیدا نمی‌کند

Smoke معمولاً Testها را در سطح Broad & Shallow اجرا می‌کند. بنابراین ممکن است یک قابلیت در سطح اولیه درست به نظر برسد، اما در شرایط پیچیده مشکل داشته باشد.

Payment
   ↓
Basic Payment → PASS

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

Refund
Partial Payment
Payment Timeout
Duplicate Transaction
Currency Conversion

Smoke لزوماً این موارد را بررسی نمی‌کند.

۳. جایگزین Regression Testing نیست

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

Smoke
  ↓
Build Health

Regression
  ↓
Impact of Changes

این دو Test هدف متفاوتی دارند.

۴. امکان ایجاد False Confidence

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

Smoke سبز است، پس Release مشکلی ندارد.

این نتیجه‌گیری اشتباه است. Smoke فقط نشان می‌دهد سناریوهای انتخاب‌شده موفق بوده‌اند.

۵. Smoke Suite ممکن است Flaky شود

اگر Automated Smoke Testها ناپایدار باشند، تیم ممکن است مرتباً Failureهای غیرواقعی دریافت کند.

Application = Healthy

Smoke
 ↓
FAIL
 ↓
Environment Problem

اگر این اتفاق زیاد تکرار شود، اعتماد تیم به Smoke Suite کاهش پیدا می‌کند.

۶. نیاز به Maintenance

Application دائماً تغییر می‌کند و در نتیجه Smoke Suite نیز باید به‌روزرسانی شود.

Old Locator
    ↓
Broken Test

Old Smoke Scenario
        ↓
Outdated

بنابراین Automated Smoke Testها نیز Maintenance Cost دارند.

۷. کیفیت Smoke به انتخاب Test Case وابسته است

ممکن است یک تیم Smoke Testing داشته باشد، اما Test Caseهای اشتباهی را انتخاب کرده باشد.

Smoke Suite

Profile Picture
Change Theme
Update Bio

در حالی که Critical Flowهایی مانند موارد زیر اصلاً بررسی نمی‌شوند:

Login
Checkout
Payment

در چنین شرایطی داشتن Smoke Suite لزوماً به معنی داشتن Smoke Testing مؤثر نیست.

Smoke Testing در برابر هزینه آن

یک Smoke Suite باید بین Coverage و Execution/Maintenance Cost تعادل برقرار کند.

اگر تعداد Testها خیلی کم باشد، Coverage ممکن است ناکافی باشد؛ و اگر تعداد Testها بیش از حد زیاد شود، Smoke تبدیل به یک Suite سنگین و کند خواهد شد.

Coverage
   ↑
   │           ●
   │        ●
   │     ●
   │   ●
   │ ●
   └────────────────→ Cost

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

آیا Smoke Testing همیشه ارزش دارد؟

در بسیاری از پروژه‌هایی که Buildهای متعدد، سیستم نسبتاً پیچیده، تست‌های زیاد، Releaseهای مکرر یا CI/CD دارند، Smoke Testing می‌تواند بسیار ارزشمند باشد.

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

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

Smoke Testing به‌عنوان Risk Reduction Tool

Smoke Testing قرار نیست همه Riskهای محصول را پوشش دهد. کار اصلی آن کاهش یک Risk مشخص است:

ریسک اینکه تیم QA زمان زیادی را روی یک Build ناسالم صرف کند.

به همین دلیل Smoke را می‌توان یک Early Feedback Mechanism و Risk Reduction Technique دانست.

جمع‌بندی مزایا و محدودیت‌های Smoke Testing

مزایا	محدودیت‌ها
Feedback سریع	Coverage محدود
شناسایی مشکلات Critical	عدم کشف بسیاری از Bugهای عمیق
کاهش اتلاف زمان	جایگزین Regression نیست
مناسب برای Automation	امکان ایجاد False Confidence
مناسب برای CI/CD	نیازمند Maintenance
کمک به Build Decision	وابسته به کیفیت Smoke Suite
مناسب برای Releaseهای مکرر	احتمال Flaky شدن Automation

نتیجه نهایی

Smoke Testing یک فیلتر اولیه کیفیت است، نه یک سیستم کامل برای ارزیابی کیفیت نرم‌افزار.

اگر درست طراحی شود:

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

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

Smoke
  ↓
Build Health
  ↓
Functional / Integration
  ↓
Regression
  ↓
Other Testing
  ↓
Release Decision

Smoke فقط اولین فیلتر است؛ نه آخرین قضاوت درباره کیفیت محصول.

Smoke Testing Checklist

داشتن یک Checklist مشخص باعث می‌شود Smoke Testing به فرآیندی وابسته به تجربه شخصی QA تبدیل نشود. این Checklist کمک می‌کند قبل از شروع تست، شرایط Build و Environment بررسی شوند، اجرای Smoke به‌صورت منظم انجام شود و در صورت Failure نیز تصمیم مناسبی درباره ادامه Testing گرفته شود.

می‌توان فرآیند Smoke Testing را به چهار مرحله اصلی تقسیم کرد:

Before Smoke
     ↓
During Smoke
     ↓
Failure Handling
     ↓
After Smoke

۱. Checklist قبل از Smoke Testing

قبل از شروع اجرای Smoke Test، ابتدا باید مطمئن شویم Build، Environment و Test Data برای اجرای تست آماده هستند.

Build

Build جدید دریافت شده است.
Build Version مشخص است.
Deployment با موفقیت انجام شده است.
Release Notes یا اطلاعات مربوط به تغییرات در دسترس است.
Known Issues مشخص هستند.

Environment

Application در دسترس است.
Environment صحیح انتخاب شده است.
Database در دسترس است.
Serviceهای ضروری Running هستند.
Dependencyهای مهم در دسترس هستند.
Configuration موردنیاز صحیح است.

Test Data

Test User موردنیاز وجود دارد.
Test Account فعال است.
داده‌های موردنیاز آماده هستند.
Test Data با Environment هماهنگ است.
اطلاعات حساس واقعی در Test Environment استفاده نشده است.

۲. Checklist طراحی Smoke Suite

Smoke Testing زمانی مؤثر است که از قبل مشخص شده باشد چه قابلیت‌ها و مسیرهایی واقعاً برای Build Verification اهمیت دارند.

Critical Functionality مشخص شده است.
Critical User Journeyها مشخص شده‌اند.
Test Caseهای Smoke از Test Caseهای گسترده‌تر Regression تفکیک شده‌اند.
Test Caseهای غیرضروری از Smoke Suite حذف شده‌اند.
Dependency بین Test Caseها مشخص است.
Expected Result هر Test مشخص است.
Smoke Suite بیش از حد بزرگ نشده است.
Test Caseهای مناسب برای Automation مشخص شده‌اند.

۳. Checklist هنگام اجرای Smoke

Build Version صحیح بررسی شده است.
Environment صحیح استفاده می‌شود.
Test Caseها طبق Smoke Suite اجرا می‌شوند.
نتیجه هر Test ثبت می‌شود.
Failureها مستند می‌شوند.
Screenshot، Video یا Log در صورت نیاز ذخیره می‌شود.
Test Data صحیح استفاده می‌شود.
Dependency بین Test Caseها در نظر گرفته می‌شود.

۴. اگر Smoke Test Fail شد چه کنیم؟

وقتی یک Smoke Test Fail می‌شود، نباید بلافاصله نتیجه بگیریم که Build حتماً دارای یک Bug است. ابتدا باید مشخص شود Failure از کجا ناشی شده است.

Failure Investigation

Test Case دوباره بررسی شده است.
Expected Result صحیح است.
Actual Result ثبت شده است.
Environment بررسی شده است.
Test Data بررسی شده است.
Logs بررسی شده‌اند.
API Response در صورت نیاز بررسی شده است.
Dependencyهای مربوطه بررسی شده‌اند.
مشخص شده است Failure مربوط به Application، Environment، Configuration، Test Data یا خود Test است.

۵. در صورت وجود Bug

اگر بررسی‌ها نشان دهد Failure ناشی از Application است، باید آن را مطابق فرآیند Bug Management تیم مستند کرد.

Bug Report ایجاد شده است.
Build Version درج شده است.
Environment درج شده است.
Steps to Reproduce ثبت شده است.
Expected Result ثبت شده است.
Actual Result ثبت شده است.
Severity مشخص شده است.
Priority در صورت نیاز مشخص شده است.
Screenshot، Video یا Log در صورت نیاز اضافه شده است.
Developer یا Team مربوطه مطلع شده است.

۶. تصمیم درباره Build

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

اگر Smoke Pass شود:

Smoke PASS
    ↓
Build Ready for Further Testing
    ↓
Further Testing

اگر Failure مهم وجود داشته باشد:

Smoke FAIL
    ↓
Critical Failure?
   ↙        ↘
 YES        NO
  ↓          ↓
Block     Risk Assessment
Build     & Decision

نکته مهم این است که Smoke Failure همیشه به معنی Build Rejection نیست. اگر Failure مربوط به یک قابلیت کم‌ریسک باشد، ممکن است تیم با توجه به Impact، Risk و Test Strategy تصمیم بگیرد Testing را ادامه دهد.

۷. Checklist بعد از Smoke Testing

تمام Test Caseهای لازم اجرا شده‌اند.
وضعیت Pass، Fail یا Blocked ثبت شده است.
Failureهای مهم بررسی شده‌اند.
Bugهای لازم ثبت شده‌اند.
نتیجه نهایی مشخص شده است.
Build Status اعلام شده است.
تیم مربوطه از نتیجه مطلع شده است.
در صورت نیاز، Smoke روی Build جدید مجدداً اجرا خواهد شد.

۸. Checklist برای Automated Smoke

اگر Smoke Testing به‌صورت Automated اجرا می‌شود، علاوه بر موارد بالا باید پایداری و نحوه اجرای Automation نیز بررسی شود.

Smoke Suite در CI/CD اجرا می‌شود.
Test Data قابل کنترل و تکرارپذیر است.
Environment صحیح انتخاب می‌شود.
Testها تا حد امکان Flaky نیستند.
Execution Time قابل قبول است.
Failureها Log مناسب دارند.
Screenshot یا Trace در صورت Failure ذخیره می‌شود.
Test Report تولید می‌شود.
Pipeline می‌تواند بر اساس نتیجه Smoke تصمیم‌گیری کند.
Smoke Testها به‌صورت دوره‌ای Maintenance و Review می‌شوند.

Smoke Testing Checklist نهایی

اگر بخواهیم همه موارد را در یک Checklist کوتاه و قابل استفاده در پروژه خلاصه کنیم:

Before Smoke

Build مشخص است.
Deployment موفق است.
Environment سالم است.
Dependencyها در دسترس هستند.
Test Data آماده است.
Smoke Suite مشخص است.

During Smoke

Critical Flowها اجرا شدند.
نتایج ثبت شدند.
Failureها مستند شدند.
Evidence لازم ذخیره شد.

Failure Handling

Failure بررسی شد.
Environment بررسی شد.
Test Data بررسی شد.
Root Cause احتمالی مشخص شد.
Bug در صورت نیاز ثبت شد.
Impact و Risk بررسی شدند.

After Smoke

Pass، Fail یا Blocked مشخص است.
Build Status مشخص است.
نتیجه به تیم اعلام شده است.
در صورت نیاز Build جدید درخواست شده است.
Smoke در صورت نیاز مجدداً اجرا شده است.

یک نکته حرفه‌ای: Smoke Suite یک سند زنده است

Smoke Checklist و Smoke Suite نباید برای همیشه ثابت بمانند. با تغییر Application، Critical Pathها، Business Riskها و Architecture ممکن است نیاز باشد Testهای Smoke نیز بازبینی شوند.

Version 1
Login
Search
Cart
Checkout

        ↓ New Critical Feature

Version 2
Login
Search
Cart
Checkout
Subscription

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

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

خلاصه نهایی Checklist

برای استفاده سریع در پروژه، می‌توان چهار سؤال زیر را به‌عنوان هسته اصلی Smoke Checklist در نظر گرفت:

آیا Build و Environment آماده‌اند؟
آیا Critical Functionality کار می‌کند؟
اگر Failure داریم، علت آن چیست؟
آیا Build برای ادامه Testing مناسب است؟

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

اشتباهات رایج در Smoke Testing و باورهای غلط

Smoke Testing ساده به نظر می‌رسد، اما در عمل اشتباهات زیادی در طراحی و اجرای آن رخ می‌دهد. بعضی از این اشتباهات ناشی از اجرای نادرست هستند و بعضی دیگر از برداشت‌های اشتباه درباره مفهوم Smoke Testing ناشی می‌شوند.

اشتباه ۱: تصور اینکه Smoke Testing یعنی تست کردن همه‌چیز به‌صورت سریع

یکی از رایج‌ترین برداشت‌های اشتباه این است که Smoke یعنی کل Application را سریع تست کنیم. این تعریف دقیق نیست.

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

Login
Search
Product
Cart
Checkout

در مقابل، مواردی مانند Advanced Search Filters، Reports، User Preferences و Edge Cases لزوماً بخشی از Smoke Suite نیستند.

اشتباه ۲: هرچه Test Case بیشتر، Smoke بهتر

Smoke Suite بزرگ‌تر لزوماً Smoke Suite بهتری نیست.

Suite A → 15 Tests → 3 minutes
Suite B → 250 Tests → 70 minutes

اگر Smoke بیش از حد بزرگ شود، ممکن است دیگر نقش یک Early Build Verification سریع را به‌خوبی انجام ندهد.

هدف باید این باشد:

Maximum Useful Signal with Minimum Necessary Tests

اشتباه ۳: یکی دانستن Smoke Testing و Regression Testing

Smoke و Regression هدف یکسانی ندارند.

Smoke: آیا Build در سطح کلی و Critical قابل تست است؟
Regression: آیا تغییرات جدید باعث خرابی قابلیت‌های قبلی شده‌اند؟

اشتباه ۴: تصور اینکه Smoke همیشه Manual است

Smoke Testing می‌تواند Manual، Automated یا ترکیبی از هر دو باشد.

Deploy
 ↓
Automated Smoke
 ↓
PASS / FAIL

بنابراین Smoke یک Testing Activity است و Manual یا Automated بودن، روش اجرای آن را مشخص می‌کند.

اشتباه ۵: تصور اینکه Smoke همیشه باید با UI انجام شود

Smoke Testing محدود به UI نیست و بسته به Architecture و هدف تست می‌تواند در لایه‌های مختلف انجام شود.

Smoke
 ├── UI
 ├── API
 ├── Service
 └── Integration

برای مثال، اگر هدف بررسی سلامت یک API حیاتی باشد، ممکن است API Smoke Test انتخاب مناسب‌تری نسبت به UI Test باشد.

اشتباه ۶: مساوی دانستن Smoke PASS با بدون Bug بودن Build

Pass شدن Smoke به معنی Bug Free بودن Build نیست.

Smoke Suite
20 Tests
20 PASS

        ↓

Critical Flow → PASS
Advanced Feature → ممکن است FAIL باشد
Rare Scenario → ممکن است FAIL باشد
Performance Issue → ممکن است وجود داشته باشد
Security Issue → ممکن است وجود داشته باشد

Smoke PASS ≠ Bug Free

اشتباه ۷: Smoke Failure را بدون بررسی، Bug فرض کنیم

اگر Login Test با Failure مواجه شود، علت می‌تواند Bug، مشکل Environment، Network، Test Data، Configuration، Dependency یا حتی مشکل Automation باشد.

بنابراین QA باید ابتدا Failure را تحلیل کند و سپس درباره علت آن تصمیم بگیرد.

اشتباه ۸: اجرای Smoke بدون توجه به Dependency

Login
 ↓
Search
 ↓
Cart
 ↓
Checkout
 ↓
Payment

اگر Login Fail شود، اجرای Testهای بعدی که مستقیماً به Login وابسته هستند ممکن است ارزش محدودی داشته باشد. بنابراین Dependency بین Test Caseها باید در طراحی Smoke Suite در نظر گرفته شود.

اشتباه ۹: ساختن Smoke Suite و تغییر ندادن آن

Application ثابت نمی‌ماند و Critical Pathهای آن ممکن است با گذشت زمان تغییر کنند. بنابراین Smoke Suite نیز باید همراه با تغییرات مهم محصول بازبینی شود.

اشتباه ۱۰: استفاده از Retry برای پنهان کردن Flaky Test

Retry در بعضی شرایط می‌تواند مفید باشد، اما نباید جایگزین بررسی Flaky Test شود.

Run 1 → FAIL
Run 2 → PASS
Run 3 → PASS

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

اشتباه ۱۱: بزرگ کردن بیش از حد Smoke Suite

گاهی با گذشت زمان هر Test Case جدیدی به Smoke اضافه می‌شود و Suite به‌تدریج سنگین‌تر می‌شود.

Smoke
 ↓
+ Test
 ↓
+ Test
 ↓
+ Test
 ↓
+ Test
 ↓
Regression-like Suite

هر Test جدید باید با این سؤال ارزیابی شود:

آیا این Test واقعاً برای Build Verification حیاتی است؟

اشتباه ۱۲: تعیین Criticality فقط بر اساس Technical Importance

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

Feature A
Technical Complexity: High
Business Impact: Low

Feature B
Technical Complexity: Low
Business Impact: Critical

بنابراین در طراحی Smoke Suite باید علاوه بر جنبه فنی، Business Risk و Business Impact نیز در نظر گرفته شوند.

اشتباه ۱۳: استفاده از Smoke بدون Definition مشخص در تیم

یکی از مشکلات رایج این است که هر عضو تیم تعریف متفاوتی از Smoke داشته باشد. این اختلاف برداشت می‌تواند میان QA، Developer و Release Team باعث سردرگمی شود.

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

Smoke Suite مجموعه‌ای از تست‌های سریع و Critical است که برای بررسی حداقل سلامت Build و تصمیم درباره ادامه Testing اجرا می‌شود.

اشتباه ۱۴: فراموش کردن Maintenance

Automated Smoke Testها نیز مانند سایر Software Assets به Maintenance نیاز دارند.

Smoke Automation
       ↓
Maintenance
       ↓
Refactoring
       ↓
Review

در غیر این صورت Testها ممکن است Outdated، Flaky یا مستعد False Failure شوند و Critical Flowهای جدید را نیز پوشش ندهند.

اشتباه ۱۵: استفاده از Smoke به‌عنوان تنها Quality Gate

Smoke می‌تواند یک Quality Gate مفید باشد، اما نباید تنها معیار تصمیم‌گیری درباره کیفیت و Release باشد.

Smoke PASS
     ↓
Functional Testing
     ↓
Security
     ↓
Performance
     ↓
Accessibility
     ↓
Release Decision

باور غلط: Smoke باید همیشه قبل از هر تست دیگری اجرا شود

این جمله بیش از حد مطلق است. Smoke معمولاً برای Build Verification در ابتدای چرخه تست بسیار مفید است، اما محل دقیق آن به Pipeline و Test Strategy پروژه بستگی دارد.

Commit
 ↓
Unit Tests
 ↓
Build
 ↓
Deploy
 ↓
Smoke

بنابراین Smoke الزاماً اولین Test در کل فرآیند نیست.

باور غلط: Smoke فقط برای Build جدید است

Smoke Testing بیشتر با Build Verification شناخته می‌شود، اما بسته به Test Strategy می‌تواند پس از Deployment، Release یا برخی تغییرات مهم Environment و Configuration نیز مورد استفاده قرار گیرد.

باور غلط: Smoke باید همیشه سریع‌ترین Test موجود باشد

Smoke باید برای Feedback اولیه به اندازه کافی سریع باشد، اما هدف آن صرفاً رسیدن به کمترین زمان ممکن نیست. اگر یک Critical Check کمی بیشتر زمان ببرد اما Signal بسیار مهمی ایجاد کند، ممکن است همچنان ارزش قرار گرفتن در Smoke Suite را داشته باشد.

Fast Enough for Early Feedback

باور غلط: هر Failure در Smoke یعنی Release باید متوقف شود

تصمیم درباره توقف Release به Criticality، Impact، Risk و Strategy پروژه بستگی دارد.

Smoke Failure
      ↓
Critical?
 ┌────┴────┐
YES        NO
 ↓          ↓
Block      Risk Assessment

۱۰ باور غلط مهم در یک نگاه

باور غلط	واقعیت
Smoke یعنی تست سریع همه‌چیز	❌
Test بیشتر یعنی Smoke بهتر	❌
Smoke همان Regression است	❌
Smoke فقط Manual است	❌
Smoke فقط UI است	❌
Smoke PASS یعنی بدون Bug	❌
هر Smoke Failure یک Bug است	❌
Smoke Suite نباید تغییر کند	❌
Retry مشکل Flaky Test را حل می‌کند	❌
Smoke تنها Quality Gate است	❌

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

بزرگ‌ترین اشتباه درباره Smoke Testing این است که آن را یک تست ساده با چند Test Case ثابت بدانیم. Smoke Testing مؤثر نیازمند Risk Analysis، Critical Path Identification، Scope مناسب، اجرای پایدار و Feedback سریع است.

Smoke Testing برای اثبات کیفیت کامل سیستم نیست؛ برای کاهش سریع ریسک ادامه تست روی یک Build ناسالم است.

Case Study عملی Smoke Testing؛ از Build تا تصمیم نهایی

برای اینکه مفهوم Smoke Testing کاملاً روشن شود، یک سناریوی واقعی‌نما از یک فروشگاه اینترنتی را بررسی کنیم. فرض کنید تیم در حال توسعه یک E-Commerce Application است و نسخه جدیدی از سیستم برای تست در اختیار QA قرار می‌گیرد.

وضعیت پروژه

E-Commerce Application

├── Authentication
├── Product Catalog
├── Search
├── Cart
├── Checkout
├── Payment
├── Order Management
└── Notification

تیم QA یک Smoke Suite شامل ۲۵ Test Case دارد که عمدتاً Critical Flowهای سیستم را پوشش می‌دهد.

مرحله اول: دریافت Build

Developer اعلام می‌کند:

Build 4.6.0 deployed to QA environment.

مورد	مقدار
Build	4.6.0
Environment	QA
Deployment	Successful
Database	Available
Payment Service	Available

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

مرحله دوم: Environment Check

Application → Available
Database → Available
Authentication Service → Available
Product Service → Available
Payment Service → Available

همه موارد PASS هستند و بنابراین Environment برای اجرای Smoke آماده است.

مرحله سوم: اجرای Smoke Suite

Test	Result
Application Launch	PASS
Login	PASS
Search Product	PASS
Product Details	PASS
Add to Cart	PASS
Update Cart	PASS
Checkout	FAIL

در اینجا Smoke متوقف یا محدود می‌شود، زیرا Checkout یکی از Critical Flowهای سیستم است و Failure آن می‌تواند ادامه بخشی از تست‌های مرتبط را کم‌ارزش کند.

مرحله چهارم: بررسی Failure

QA ابتدا فرض نمی‌کند که مشکل حتماً یک Application Bug است.

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

Application درست اجرا می‌شود.
Login موفق است.
Product درست کار می‌کند.
Cart درست کار می‌کند.
Checkout با خطای HTTP 500 مواجه می‌شود.

با بررسی Logs مشخص می‌شود:

Payment Service Connection Timeout

مرحله پنجم: تشخیص Root Cause

QA با تیم Developer و DevOps موضوع را بررسی می‌کند. مشخص می‌شود Configuration مربوط به Payment Service در Build جدید به‌درستی تنظیم نشده است.

Smoke Failure
      ↓
Checkout
      ↓
HTTP 500
      ↓
Payment Service Timeout
      ↓
Configuration Problem

بنابراین Failure ناشی از یک Bug در Business Logic نیست و مشکل از Configuration است.

مرحله ششم: آیا Build باید Block شود؟

با توجه به اینکه Checkout یکی از Critical Business Flowهای سیستم است، تیم تصمیم می‌گیرد تا زمان برطرف شدن مشکل، Build برای ادامه تست‌های گسترده Block شود.

Build 4.6.0 — BLOCKED

مرحله هفتم: اصلاح مشکل

DevOps Configuration مربوط به Payment Service را اصلاح می‌کند. سپس Build جدید ایجاد و روی QA Environment Deploy می‌شود:

Build 4.6.1

مرحله هشتم: اجرای مجدد Smoke

Test	Result
Application Launch	PASS
Login	PASS
Search Product	PASS
Product Details	PASS
Add to Cart	PASS
Update Cart	PASS
Checkout	PASS
Payment	PASS
Order Creation	PASS

این بار Critical Flowهای موردنظر Smoke با موفقیت اجرا می‌شوند.

مرحله نهم: آیا کار تمام شده است؟

خیر.

Smoke فقط نشان داده است که Build در سطح اولیه برای ادامه Testing مناسب به نظر می‌رسد. بنابراین حالا می‌توان تست‌های گسترده‌تر را آغاز کرد:

Smoke PASS
    ↓
Functional Testing
    ↓
Integration Testing
    ↓
Regression Testing
    ↓
Performance / Security / Accessibility
    ↓
Release Decision

یک تغییر دیگر: Discount

فرض کنید Developer در همین Build منطق Discount را نیز تغییر داده است. Smoke همچنان Pass می‌شود، اما این به معنی درست بودن Discount نیست؛ زیرا ممکن است Discount در Smoke Suite قرار نداشته باشد.

Coupon: SAVE20
Expected Discount: 20%
Actual Discount: 10%

این مثال نشان می‌دهد که Smoke PASS همچنان نمی‌تواند جایگزین Functional یا Regression Testing شود.

این Case Study چه چیزی را نشان می‌دهد؟

۱. Deployment موفق ≠ Build سالم

ممکن است Deployment کاملاً موفق باشد، اما Application پس از آن همچنان با مشکل مواجه شود.

۲. Smoke Failure ≠ همیشه Application Bug

Failure می‌تواند ناشی از Application، Configuration، Environment، Test Data، Dependency یا Automation باشد.

۳. Smoke PASS ≠ Bug Free

ممکن است قابلیت‌هایی خارج از Smoke Suite همچنان دارای Bug باشند.

۴. Criticality در تصمیم‌گیری اهمیت دارد

Failure در Checkout معمولاً Impact بیشتری نسبت به Failure در یک قابلیت کم‌اهمیت مانند Change Profile Picture دارد و می‌تواند تصمیم تیم درباره Block کردن Build را تغییر دهد.

نسخه Automated همین سناریو

اگر Smoke Suite Automated شده باشد، می‌تواند مستقیماً به CI/CD Pipeline متصل شود.

Developer Commit
       ↓
Build 4.6.1
       ↓
Deploy QA
       ↓
API Smoke
       ↓
UI Smoke
       ↓
PASS
       ↓
Pipeline Continues

اگر Checkout Failure ایجاد کند، Pipeline می‌تواند نتیجه Smoke را به‌عنوان یک Failure پردازش کند:

Deploy
 ↓
Smoke
 ↓
Checkout FAIL
 ↓
Pipeline FAILED
 ↓
Team Notification

نمونه گزارش نهایی Smoke

SMOKE TEST REPORT

Build: 4.6.1
Environment: QA

Total Tests: 25
Passed: 25
Failed: 0
Blocked: 0

Status: PASS

Critical Flows:
✓ Login
✓ Search
✓ Cart
✓ Checkout
✓ Payment
✓ Order Creation

Recommendation:
Build is ready for further testing.

اگر Smoke Fail شود چه گزارشی بدهیم؟

SMOKE TEST REPORT

Build: 4.6.0
Environment: QA

Total Tests: 25
Passed: 6
Failed: 1
Blocked: 18

Status: BLOCKED

Critical Failure:
Checkout returns HTTP 500.

Root Cause:
Payment Service configuration issue.

Recommendation:
Do not proceed with full test execution.

این نوع گزارش برای تیم بسیار ارزشمندتر از یک پیام ساده مانند «Smoke Fail شد» است، زیرا وضعیت Build، Failure مهم، Root Cause و Recommendation را مشخص می‌کند.

درس اصلی Case Study

Smoke Testing در واقع یک سؤال ساده اما مهم را پاسخ می‌دهد:

آیا این Build حداقل شرایط لازم برای ادامه فرآیند تست را دارد؟

Build 4.6.0
     ↓
Smoke FAIL
     ↓
Build BLOCKED
     ↓
Fix
     ↓
Build 4.6.1
     ↓
Smoke PASS
     ↓
Further Testing

این همان نقشی است که Smoke Testing باید در فرآیند QA ایفا کند: ارائه یک سیگنال سریع و قابل اتکا برای تصمیم‌گیری درباره ادامه Testing.

یک نکته حرفه‌ای درباره Smoke Testing

Smoke Testing به‌تنهایی کیفیت محصول را ارزیابی نمی‌کند؛ بلکه بیشتر به این سؤال پاسخ می‌دهد که آیا Build برای ورود به مراحل بعدی Testing مناسب است یا خیر.

Smoke Testing یک «لیست تست‌های سریع» صرف نیست؛ بلکه بخشی از Build Verification Strategy است.

جمع‌بندی Case Study

Build جدید دریافت شد.
Environment بررسی شد.
Smoke Suite اجرا شد.
Checkout Fail شد.
Failure تحلیل شد.
مشخص شد مشکل Configuration است.
Build Block شد.
مشکل برطرف شد.
Build جدید Deploy شد.
Smoke مجدداً اجرا شد.
Smoke Pass شد.
Build وارد مراحل تست گسترده‌تر شد.

بنابراین Smoke Testing را می‌توان به‌صورت یک چرخه ساده اما مهم خلاصه کرد:

Build → Verify → Analyze → Decide → Re-test → Continue

سوالات متداول Smoke Testing

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

Smoke Testing چیست؟

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

چرا Smoke Testing انجام می‌شود؟

هدف اصلی Smoke Testing، شناسایی سریع مشکلات مهم در Build و جلوگیری از صرف زمان روی Buildهایی است که از ابتدا مشکلات اساسی دارند.

آیا Smoke Testing همان Regression Testing است؟

خیر. Smoke Testing بیشتر روی سلامت اولیه Build و Critical Flowها تمرکز دارد، در حالی که Regression Testing بررسی می‌کند آیا تغییرات جدید باعث خراب شدن قابلیت‌هایی شده‌اند که قبلاً درست کار می‌کردند یا خیر.

آیا Smoke Testing و Sanity Testing یکی هستند؟

این موضوع به Terminology مورد استفاده تیم یا منبع بستگی دارد. در کاربرد رایج بسیاری از تیم‌ها، Sanity Testing به تست محدود و هدفمند یک Change یا Fix گفته می‌شود؛ اما در Terminology رسمی ISTQB، Sanity Test به‌عنوان Synonym برای Smoke Test آمده است. بنابراین بهتر است Definition داخلی تیم مشخص باشد.

آیا Smoke Testing فقط به‌صورت Manual انجام می‌شود؟

خیر. Smoke Testing می‌تواند به‌صورت Manual، Automated یا ترکیبی از هر دو انجام شود. در تیم‌های Agile و DevOps، Automated Smoke Test می‌تواند در CI/CD Pipeline اجرا شود.

آیا Smoke Testing فقط برای تست UI است؟

خیر. Smoke Test می‌تواند در لایه‌های مختلف مانند UI، API، Service و Integration اجرا شود. برای مثال، بررسی سلامت یک API حیاتی می‌تواند بخشی از API Smoke Suite باشد.

چند Test Case باید در Smoke Suite داشته باشیم؟

عدد ثابتی وجود ندارد. Smoke Suite باید آن‌قدر بزرگ باشد که Critical Functionality را پوشش دهد و در عین حال آن‌قدر کوچک بماند که Feedback اولیه را سریع ارائه کند. تعداد مناسب Test Caseها به اندازه، پیچیدگی و ریسک پروژه بستگی دارد.

آیا باید بعد از هر Build Smoke Testing انجام شود؟

الزاماً نه. در بسیاری از تیم‌ها Smoke بعد از Buildهای مهم یا Deploymentهای جدید اجرا می‌شود، اما اجرای آن بعد از هر Build به عواملی مانند سرعت Pipeline، تعداد Buildها، هزینه اجرای تست، Environment و اندازه Smoke Suite بستگی دارد.

آیا Smoke Testing باید قبل از Regression Testing انجام شود؟

در یک Workflow رایج، ابتدا Smoke بررسی می‌کند که Build حداقل سلامت لازم را دارد و سپس تست‌های گسترده‌تر مانند Regression اجرا می‌شوند. با این حال، این ترتیب یک قانون جهانی نیست و می‌تواند بر اساس Test Strategy پروژه متفاوت باشد.

آیا Smoke PASS یعنی نرم‌افزار Bug ندارد؟

خیر. Smoke فقط تعداد محدودی از Critical Flowها را بررسی می‌کند. ممکن است Smoke کاملاً Pass شود، اما در قابلیت‌هایی که در Smoke Suite قرار ندارند، Bugهای مهمی وجود داشته باشد. بنابراین Smoke PASS ≠ Bug Free.

آیا هر Smoke Failure به معنی وجود Bug است؟

خیر. Failure ممکن است ناشی از Application Bug، Environment Problem، Configuration، Test Data، Network، Dependency یا Automation Problem باشد. بنابراین قبل از ثبت Bug باید Failure بررسی و علت آن مشخص شود.

آیا Smoke Failure همیشه باعث توقف تست می‌شود؟

خیر. اگر Failure مربوط به یک Critical Functionality باشد، ممکن است Build Block شود. اما اگر Failure مربوط به قابلیت کم‌اهمیت‌تری باشد، تیم می‌تواند بر اساس Risk و Impact درباره ادامه Testing تصمیم بگیرد.

آیا Smoke Testing در CI/CD قابل استفاده است؟

بله. یکی از کاربردهای مهم Automated Smoke Testing، اجرای آن بعد از Deployment در CI/CD Pipeline است. در این حالت Smoke می‌تواند به‌عنوان یک Quality Gate عمل کند و بر اساس نتیجه آن، Pipeline ادامه پیدا کند یا متوقف شود.

آیا Smoke Testing برای Production هم انجام می‌شود؟

می‌تواند انجام شود، اما باید با احتیاط طراحی شود. بعد از Production Deployment می‌توان Critical Health Checkها یا Synthetic Tests را اجرا کرد. تست‌هایی که ممکن است داده واقعی یا تراکنش مالی ایجاد کنند باید با Strategy مناسب و بدون ایجاد اثر ناخواسته طراحی شوند.

آیا Automated Smoke Testing بهتر از Manual Smoke Testing است؟

هیچ پاسخ مطلقی وجود ندارد. Automation برای Smoke Testهای تکراری، پایدار، قابل پیش‌بینی و Critical بسیار مناسب است، اما در برخی پروژه‌ها یا مراحل اولیه Manual Smoke Testing نیز می‌تواند انتخاب منطقی باشد. در بسیاری از تیم‌ها ترکیب Manual و Automation بهترین رویکرد است.

آیا Smoke Test Caseها می‌توانند در Regression Suite هم باشند؟

بله. یک Test Case می‌تواند هم در Smoke Suite و هم در Regression Suite قرار داشته باشد. برای مثال، Verify successful login می‌تواند در هر دو Suite وجود داشته باشد. تفاوت اصلی در هدف و Context اجرای Test است، نه الزاماً خود Test Case.

آیا Smoke Suite باید همیشه ثابت باشد؟

خیر. با تغییر Application، Critical Pathها و Business Riskها نیز ممکن است تغییر کنند. بنابراین Smoke Suite باید به‌صورت دوره‌ای Review شود و در صورت تغییر قابلیت‌های حیاتی، Test Caseهای آن نیز به‌روزرسانی شوند.

آیا Smoke Testing یک Test Type است؟

بهتر است Smoke Testing را به‌عنوان یک Testing Approach یا Test Activity برای Build Verification در نظر بگیریم، نه اینکه آن را صرفاً بر اساس Manual یا Automated بودن تعریف کنیم. Smoke می‌تواند با روش‌های مختلف و در لایه‌های مختلف سیستم اجرا شود.

تفاوت اصلی Smoke و Sanity چیست؟

در کاربرد رایج بسیاری از تیم‌ها، Smoke یک بررسی نسبتاً Broad برای Build Verification است، در حالی که Sanity معمولاً به بررسی Focused و محدود یک Change یا Fix اشاره دارد. با این حال، Sanity در منابع مختلف تعریف یکسانی ندارد و در Terminology رسمی ISTQB به‌عنوان Synonym برای Smoke Test نیز آمده است.

اگر فقط یک چیز درباره Smoke Testing به خاطر بسپاریم، چیست؟

این جمله را به خاطر بسپارید: Smoke Testing مشخص می‌کند آیا یک Build حداقل شرایط لازم برای ادامه فرآیند Testing را دارد یا خیر.

جمع‌بندی نهایی مقاله

Smoke Testing یک بررسی سریع و هدفمند از Critical Functionality است که معمولاً پس از Build یا Deployment انجام می‌شود. هدف آن پیدا کردن تمام Bugها نیست؛ بلکه مشخص کردن این است که آیا Build برای ورود به مراحل بعدی Testing مناسب است یا خیر.

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

        New Build
            ↓
       Smoke Testing
            ↓
       ┌────┴────┐
       ↓         ↓
     PASS       FAIL
       ↓         ↓
Further       Investigate
Testing          ↓
              Fix / New Build
                  ↓
             Smoke Again

Smoke Testing زمانی بیشترین ارزش را ایجاد می‌کند که:

Scope آن بر اساس Risk تعیین شده باشد.
Critical Pathها را پوشش دهد.
بیش از حد بزرگ نشود.
Testها پایدار باشند.
در صورت امکان Automated شود.
با CI/CD یکپارچه شود.
تیم Definition مشترکی از آن داشته باشد.

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

Smoke Testing تضمین نمی‌کند که نرم‌افزار باکیفیت یا بدون Bug است؛ فقط سطحی از اطمینان ایجاد می‌کند که Build برای ورود به مراحل بعدی Testing مناسب است.

طبقه بندی شده در:

دسته‌بندی نشده, تست نرم افزار,

اخرین بروزرسانی: شهریور 4, 1405

ESC را فشار دهید تا بسته شود

۱. Smoke Testing چیست؟

یک مثال ساده

Smoke Testing دقیقاً چه چیزی را مشخص می‌کند؟

چرا به آن Smoke Testing می‌گویند؟

یک نکته مهم درباره نام‌های Smoke و Sanity

چرا Smoke Testing مهم است؟

۱. جلوگیری از اتلاف زمان تیم QA

۲. شناسایی سریع مشکلات بحرانی

۳. جلوگیری از شروع تست روی یک Build ناسالم

۴. کاهش Feedback Time

۵. اهمیت Smoke Testing در CI/CD

۶. کمک به استفاده مؤثرتر از منابع تست

یک نکته مهم: Smoke Testing نباید تبدیل به Regression Test Suite شود

پس Smoke Testing چه مشکلی را حل می‌کند؟

Smoke Testing چه زمانی انجام می‌شود؟

۱. بعد از ایجاد یک Build جدید

۲. بعد از Deployment

۳. قبل از شروع تست‌های گسترده‌تر

۴. بعد از تغییرات مهم در سیستم

۵. در CI/CD

۶. آیا Smoke Testing باید بعد از هر تغییر اجرا شود؟

تفاوت زمان Smoke Testing با Sanity Testing

جمع‌بندی این بخش

Smoke Testing چگونه انجام می‌شود؟

۱. Build مناسب برای تست را مشخص کنید

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

۳. Smoke Test Caseها را انتخاب کنید

۴. Smoke Testها را اجرا کنید

۵. Failure را تحلیل کنید

۶. درباره Build تصمیم بگیرید

یک مثال عملی

Smoke Testing یک تست کامل نیست

یک اصل مهم در طراحی Smoke Suite

چه چیزهایی در Smoke Testing تست می‌شوند؟

۱. اجرای اولیه Application

۲. Login و Authentication

۳. Navigation اصلی

۴. قابلیت‌های Core Business

۵. APIهای حیاتی

۶. ارتباط با Database

۷. Integrationهای حیاتی

۸. مهم‌ترین مسیرهای End-to-End

معیار انتخاب یک قابلیت برای Smoke Test

یک مثال عملی برای انتخاب Smoke Test

Smoke Test باید «Critical» باشد، نه صرفاً «Important»

جمع‌بندی

چه چیزهایی نباید در Smoke Test قرار بگیرند؟

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

۲. تمام حالت‌های مثبت و منفی یک قابلیت

۳. Edge Caseها

۴. تست‌های عمیق Business Logic

۵. تست‌های Performance عمیق

۶. تست‌های Security عمیق

۷. تست‌های Compatibility گسترده

۸. تمام Regression Test Caseها

چگونه تشخیص دهیم یک Test Case مناسب Smoke است؟

خطر تبدیل Smoke Suite به Mini Regression Suite

Smoke Suite باید با سیستم تکامل پیدا کند

Smoke Testing در Agile و CI/CD

Smoke Testing در Agile

Smoke Testing در CI/CD

چرا Automation برای Smoke Testing اهمیت زیادی دارد؟

آیا همه Smoke Testها باید Automated باشند؟

Smoke Test به‌عنوان Quality Gate

Smoke Testing در Microservices

Smoke Testing و Continuous Testing

یک سناریوی واقعی در CI/CD

Smoke Test نباید Pipeline را بیش از حد کند کند

جمع‌بندی

Manual Smoke Testing در مقابل Automated Smoke Testing

Manual Smoke Testing چیست؟

مزایای Manual Smoke Testing

مناسب برای پروژه‌های کوچک

مناسب برای Featureهای جدید

مناسب برای Smoke Suiteهای اولیه

Automated Smoke Testing چیست؟

مزایای Automated Smoke Testing

۱. سرعت بیشتر

۲. اجرای مکرر