موبائل ڈویلپمنٹ میں Smoke Test — یہ کیا ہے، کام اور کیسے استعمال ہوتا ہے

مصنف: IT Sectr اشاعت: 2026-04-08 مطالعے کا وقت: 9 منٹ

Smoke Test (سموک ٹیسٹنگ) جانچوں کا ایک کم سے کم سیٹ ہے جو موبائل ایپلیکیشن بلڈ کے بعد اس بات کی تصدیق کے لیے کیا جاتا ہے کہ اہم افعال کام کر رہے ہیں۔ Smoke Test مکمل ریگریشن سائیکل چلائے بغیر غیر مستحکم بلڈز کو فوری طور پر مسترد کرنے کی اجازت دیتا ہے۔ Google Testing Blog (2024) کے مطابق، Smoke Test ڈیولپر کے لیے فیڈبیک وقت کو 2–3 گھنٹے سے کم کرکے 10–15 منٹ کر دیتا ہے۔ Smoke Test CI/CD پائپ لائن میں معیار کا پہلا فلٹر ہے جو ٹوٹے ہوئے بلڈز کو اگلے مرحلے تک پہنچنے سے روکتا ہے۔

اہم نکات

  • Smoke Test — غیر مستحکم بلڈز کو مسترد کرنے کے لیے ایپلیکیشن کے اہم افعال کی فوری جانچ۔
  • کام — صارف کے اہم راستے (لاگ ان، فیڈ، پروفائل) کی کارکردگی کی تصدیق کرنا۔
  • Smoke Test ریگریشن ٹیسٹنگ سے پہلے کیا جاتا ہے اور عموماً 5–15 منٹ لیتا ہے۔
  • CI/CD میں Smoke Test آٹومیشن جدید موبائل ڈویلپمنٹ پائپ لائن کا لازمی عنصر ہے۔
  • ریگریشن سے فرق — Smoke Test صرف اہم راستے کی جانچ کرتا ہے، ریگریشن مکمل فعالیت کو کور کرتا ہے۔

Smoke Test کیا ہے؟

Smoke Test (سموک ٹیسٹنگ) تیز رفتار ٹیسٹوں کا ایک سیٹ ہے جو گہرائی سے تجزیہ کیے بغیر ایپلیکیشن کے اہم افعال کی تصدیق کرتا ہے۔ یہ اصطلاح ہارڈویئر انجینئرنگ سے آئی ہے: اگر کوئی آلہ اسمبلی کے بعد دھواں دینے لگے تو اسے مکمل ٹیسٹنگ کے لیے نہیں بھیجا جاتا۔ موبائل ڈویلپمنٹ میں، Smoke Test وہی کام کرتا ہے — یہ واضح طور پر ناقابل استعمال بلڈز کو فلٹر کرتا ہے۔ Microsoft DevOps (2024) کے مطابق، Smoke Test کے نفاذ سے QA ٹیم تک پہنچنے والے نقائص کی تعداد 40% کم ہو جاتی ہے۔

Smoke Test ہر نئے بلڈ پر چلایا جاتا ہے — Android اور iOS دونوں پر۔ مثالی طور پر، Smoke Test کو 15 منٹ سے زیادہ نہیں لینا چاہیے اور کامیاب بلڈ کے بعد خود بخود شروع ہو جانا چاہیے۔ پاس کرنے کا معیار — Smoke Test سیٹ کے 100% ٹیسٹ کامیابی سے مکمل ہونے چاہئیں۔ اگر کم از کم ایک ٹیسٹ ناکام ہوتا ہے، تو بلڈ کو غیر مستحکم قرار دے دیا جاتا ہے اور مزید ٹیسٹنگ کے لیے نہیں بھیجا جاتا۔ Google Testing Blog (2024) کے مطابق، یہ طریقہ صارفین تک فیچر ڈیلیوری کے وقت کو 25% کم کرتا ہے۔

Smoke Test دستی (5–10 نکات کی چیک لسٹ) یا آٹومیٹڈ ہو سکتا ہے۔ جدید موبائل پروجیکٹس میں، CI/CD میں شامل آٹومیٹڈ Smoke Test کو ترجیح دی جاتی ہے۔ دستی Smoke Test صرف پروجیکٹ کے ابتدائی مراحل میں جائز ہے جب آٹومیشن اقتصادی طور پر قابل عمل نہ ہو۔ Bitrise (2025) کے مطابق، 73% موبائل ڈویلپمنٹ ٹیمیں اپنے Smoke Test کو آٹومیٹ کرتی ہیں۔

Smoke Test ریگریشن ٹیسٹنگ سے کیسے مختلف ہے؟

Smoke Test اور ریگریشن ٹیسٹنگ اکثر الجھ جاتے ہیں، لیکن یہ مختلف مقاصد کے ساتھ مختلف طرز عمل ہیں۔ ریگریشن ٹیسٹنگ تصدیق کرتی ہے کہ کوڈ میں تبدیلیوں نے موجودہ فعالیت کو نہیں توڑا ہے۔ یہ ایپلیکیشن کے تمام ماڈیولز اور منظرناموں کو کور کرتی ہے، بشمول نایاب اور حدی کیسز۔ Smoke Test صرف اہم راستے کی جانچ کرتا ہے — بنیادی منظرنامے جن کے بغیر ایپلیکیشن بیکار ہے۔ کوریج کی گہرائی بنیادی فرق ہے: Smoke Test فعالیت کا 5–10% کور کرتا ہے، ریگریشن 80–100% کور کرتی ہے۔

دوسرا فرق عملدرآمد کا وقت ہے۔ موبائل ایپلیکیشن کے لیے ریگریشن سیٹ پروجیکٹ کے سائز اور پلیٹ فارمز کی تعداد کے لحاظ سے 2 سے 12 گھنٹے لگ سکتا ہے۔ Smoke Test 5–15 منٹ لیتا ہے۔ Sauce Labs (2025) کے مطابق، iOS ایپلیکیشن کے لیے ریگریشن سیٹ کا اوسط عملدرآمد وقت 4.5 گھنٹے اور Android کے لیے — 3.2 گھنٹے ہے۔ دونوں پلیٹ فارمز پر Smoke Test 10–15 منٹ میں مکمل ہو جاتا ہے۔

تیسرا فرق پائپ لائن میں مقام ہے۔ Smoke Test بلڈ کے فوراً بعد، ریگریشن ٹیسٹنگ سے پہلے کیا جاتا ہے۔ اگر Smoke Test ناکام ہوتا ہے، تو ریگریشن شروع نہیں کی جاتی — اس سے CI/CD وسائل بچتے ہیں۔ پائپ لائن کی کارکردگی — Smoke Test 30% تک بلڈز کو فلٹر کرتا ہے جو ریگریشن میں ناکام ہوتے، اور بچائے گئے وسائل دوسرے کاموں کو متوازی طور پر چلانے کے لیے کافی ہوتے ہیں۔

پیرامیٹرSmoke Testریگریشن ٹیسٹنگ
مقصداہم راستے کی فوری جانچمکمل فعالیت کی جانچ
دائرہ کار5–10% منظرنامے80–100% منظرنامے
وقت5–15 منٹ2–12 گھنٹے
تعددہر بلڈ پرریلیز سے پہلے یا روزانہ
CI/CDبلڈ کے بعد، ریگریشن سے پہلےSmoke Test کے بعد

موبائل ایپ کے Smoke Test میں کیا شامل ہے

ایپ لانچ

ایپ لانچ — پہلا اور سب سے اہم ٹیسٹ۔ ایپلیکیشن تمام ہدف آلات پر بغیر کریش کے لانچ ہونی چاہیے۔ Smoke Test کولڈ اسٹارٹ چیک کرتا ہے: انسٹال → کھولیں → پہلی اسکرین دکھائیں۔ اگر ایپ لانچ پر کریش ہوتی ہے، تو مزید ٹیسٹنگ بے معنی ہے۔ XCUITest اور Espresso 2–3 لائنوں میں لانچ چیک کو آٹومیٹ کرنے کی اجازت دیتے ہیں۔ لانچ آرگومنٹ `-AppleLanguages (ru)` اسٹارٹ اپ پر لوکلائزیشن کی تصدیق میں مدد کرتا ہے۔

تصدیق

تصدیق — دوسرا اہم منظرنامہ۔ Smoke Test کو تصدیق کرنی چاہیے کہ لاگ ان فارم ظاہر ہوتا ہے، ان پٹ فیلڈز ٹچ پر ردعمل دیتے ہیں، لاگ ان بٹن درخواست بھیجتا ہے اور کامیاب تصدیق کے بعد ایپلیکیشن مرکزی اسکرین پر جاتی ہے۔ تصدیق کی خرابی دیگر تمام افعال تک رسائی کو روکتی ہے، اس لیے اس کی جانچ کم سے کم سیٹ میں شامل ہے۔ ٹوکن ریفریش — OAuth 2.0 استعمال کرنے والی ایپلیکیشنز کے لیے اضافی جانچ۔

مواد لوڈ کرنا اور نیویگیشن

اہم مواد کی لوڈنگ — تیسرا Smoke Test۔ ایپلیکیشن کی مرکزی اسکرین یا فیڈ لوڈ ہونی چاہیے اور ڈیٹا دکھانا چاہیے۔ اگر API جواب نہیں دیتی یا جواب کی پارسنگ ٹوٹ گئی ہے، تو صارف کو خالی اسکرین نظر آتی ہے۔ Smoke Test میں نیٹ ورک کی جانچ میں مرکزی اینڈپوائنٹ پر ایک بنیادی GET درخواست اور جواب کی متوقع ساخت کی تصدیق شامل ہے۔ نیویگیشن — چوتھا منظرنامہ۔ Smoke Test ایپلیکیشن کی مرکزی اسکرینوں پر گھومتا ہے: ہوم → تلاش → پروفائل → ترتیبات۔ ٹیب بار اور سائڈ مینو نیویگیشن مسائل کے عام ذرائع ہیں جنہیں Smoke Test ابتدائی مرحلے میں پکڑ لیتا ہے۔

CI/CD میں Smoke Test آٹومیشن

Fastlane — موبائل CI/CD آٹومیشن کے لیے معیاری ٹول۔ Fastlane میں Smoke Test `scan` (XCUITest کے لیے) یا `gradle` (Espresso کے لیے) کے ذریعے چلایا جاتا ہے۔ Fastlane ایک سے زیادہ آلات پر متوازی Smoke Test عملدرآمد کو ترتیب دینے کی اجازت دیتا ہے، جو کل وقت کم کرتا ہے۔ کنفیگریشن Fastfile میں Smoke Test سویٹ کو ہدف بنانا اور پاس تھریشولڈ شامل ہے: 100% کامیاب ٹیسٹ۔

GitHub Actions (2024) نے ایک بلٹ ان Smoke Test کے ساتھ موبائل CI/CD ٹیمپلیٹ شائع کیا۔ ٹیمپلیٹ میں تین مراحل شامل ہیں: بلڈ → Smoke Test → ریگریشن۔ اگر Smoke Test ناکام ہوتا ہے، ٹیمپلیٹ خود بخود پائپ لائن ختم کرتا ہے اور Slack یا Telegram کو اطلاع بھیجتا ہے۔ میٹرکس حکمت عملی ایک ساتھ تین iOS ورژنز اور پانچ Android ماڈلز پر Smoke Test چلانے کے قابل بناتی ہے۔

CI/CD میں ذمہ داری کی تقسیم: Smoke Test فوری فیڈبیک فراہم کرتا ہے، جبکہ ریگریشن مکمل کوریج فراہم کرتی ہے۔ Smoke Test کو ریگریشن کی نقل نہیں کرنی چاہیے، اور اس کے برعکس بھی۔ Smoke Test کی گرانولریٹی — فی اہم منظرنامہ ایک جانچ۔ اگر Smoke Test 15 منٹ سے زیادہ لیتا ہے، تو اسے بہتر بنانے کی ضرورت ہے: غیر ضروری جانچیں ہٹائیں یا عملدرآمد کو متوازی کریں۔

ruby
# Smoke Test کے لیے Fastfile کنفیگریشن
platform :ios do
    lane :smoke do
        scan(
            scheme: 'App',
            devices: ['iPhone 15', 'iPhone SE'],
            testplan: 'SmokeTest',
            output_directory: 'reports/smoke',
            fail_build: true
        )
    end

    lane :regression do
        scan(
            scheme: 'App',
            devices: ['iPhone 15', 'iPhone 14', 'iPhone SE'],
            testplan: 'FullRegression'
        )
    end
end

Smoke Test کے اوزار

XCUITest — iOS ایپلیکیشنز کے UI ٹیسٹنگ کے لیے Apple کا فریم ورک۔ XCUITest Smoke Tests کو آٹومیٹ کرنے کے لیے استعمال ہوتا ہے: ایپ لانچ کرنا، UI عناصر کی جانچ کرنا، صارف کے اعمال کا سمولیشن۔ Xcode Server یا GitHub Actions کے ساتھ مل کر، XCUITest ہر commit پر چلتا ہے۔ XCTest — یونٹ ٹیسٹس کے لیے بنیادی فریم ورک جو منطق کی تصدیق کے لیے XCUITest کی تکمیل کرتا ہے۔

Espresso — Android کے UI ٹیسٹنگ کے لیے Google کا فریم ورک۔ Espresso UI تھریڈ کے ساتھ ہم آہنگ ہوتا ہے اور اس بات کو یقینی بناتا ہے کہ جانچ شروع ہونے سے پہلے تمام اینیمیشن مکمل ہو جائیں۔ Espresso `onView(withId(...)).check(matches(...))` کے ذریعے جانچ کی حمایت کرتا ہے۔ Android Test Orchestrator ہر Smoke Test کو ایک علیحدہ عمل میں چلاتا ہے، جو پچھلے ٹیسٹوں کو بعد کے ٹیسٹوں کو متاثر کرنے سے روکتا ہے۔

Detox — React Native کے لیے ایک فریم ورک جو Smoke Test اور گرے-باکس ٹیسٹنگ کو سپورٹ کرتا ہے۔ Detox React Native برج کے ساتھ ہم آہنگ ہوتا ہے اور خود بخود غیر متزامن کارروائیوں کے مکمل ہونے کا انتظار کرتا ہے۔ گرے-باکس ٹیسٹنگ Detox کو سورس کوڈ تک براہ راست رسائی کے بغیر ایپلیکیشن کی حالت کی تصدیق کرنے کی اجازت دیتی ہے۔

Swift اور Kotlin میں Smoke Test کی مثال

XCUITest iOS کے لیے دو جانچیں شامل کرتا ہے: ایپلیکیشن لانچ کرنا اور مرکزی اسکرین دکھانا۔ ٹیسٹ `XCUIApplication().launch()` کے ذریعے ایپ لانچ کرتا ہے اور چیک کرتا ہے کہ ایک اہم عنصر (مثلاً `navigationBar`) موجود ہے۔ اگر ایپ لانچ پر کریش ہوتی ہے، XCTest فریم ورک خرابی ریکارڈ کرتا ہے اور ٹیسٹ FAIL کے ساتھ ختم ہوتا ہے۔ Smoke Test مواد کی جانچ نہیں کرتا — صرف یہ کہ اسکرین کھل گئی۔

Espresso Android کے لیے Activity لانچ کرنے کے لیے `ActivityScenario` اور عناصر کی جانچ کے لیے `onView` استعمال کرتا ہے۔ پلیٹ فارمز کے درمیان ایک اہم فرق: iOS سمیلیٹر حقیقی ڈیوائس سے مختلف رویہ دکھا سکتا ہے، اس لیے Android Smoke Tests کو Firebase Test Lab یا ایمولیٹر پر چلانے کی سفارش کی جاتی ہے۔ Firebase Test Lab 10 آلات پر Smoke Tests کے متوازی عملدرآمد کی حمایت کرتا ہے۔

swift
import XCTest

class LoginSmokeTest: XCTestCase {
    let app = XCUIApplication()

    override func setUp() {
        continueAfterFailure = false
        app.launch()
    }

    func testLoginButtonExists() {
        XCTAssertTrue(app.buttons["لاگ ان"].exists)
    }

    func testLoginFlow() {
        app.textFields["email"].tap()
        app.textFields["email"].typeText("test@test.com")
        app.secureTextFields["password"].tap()
        app.secureTextFields["password"].typeText("password123")
        app.buttons["Log In"].tap()
        XCTAssertTrue(app.staticTexts["Welcome"].waitForExistence(timeout: 5))
    }
}

اوپر دی گئی مثال iOS پر لاگ ان اسکرین کے لیے Smoke Test دکھاتی ہے۔ پہلا ٹیسٹ چیک کرتا ہے کہ لاگ ان بٹن اسکرین پر موجود ہے۔ دوسرا ٹیسٹ مکمل تصدیقی راستہ چلاتا ہے اور چیک کرتا ہے کہ کامیاب لاگ ان کے بعد ایک خوش آمدید پیغام ظاہر ہوتا ہے۔ `waitForExistence` کے لیے ٹائم آؤٹ 5 سیکنڈ Smoke Test کے لیے معیاری قدر ہے: اگر UI عنصر اس وقت میں ظاہر نہیں ہوتا، تو ایپلیکیشن صحیح طریقے سے کام نہیں کر رہی۔

اکثر پوچھے گئے سوالات

Smoke Test میں کتنے ٹیسٹ ہونے چاہئیں؟

بہترین تعداد 5 سے 15 ٹیسٹ فی ماڈیول ہے۔ Smoke Test کو صارف کے اہم راستے کو کور کرنا چاہیے لیکن پوری فعالیت کو کور کرنے کی کوشش نہیں کرنی چاہیے۔ معیار — اگر تمام Smoke Test پاس ہو جائیں، تو ایپلیکیشن کو مزید ٹیسٹنگ کے لیے QA ماحول میں کھولا جا سکتا ہے۔

Smoke Test sanity check سے کیسے مختلف ہے؟

Smoke Test بلڈ استحکام کی جانچ کرتا ہے اور ہر بلڈ پر چلتا ہے۔ Sanity check ٹیسٹوں کا ایک تنگ سیٹ ہے جو مخصوص تبدیلیوں کے بعد کیا جاتا ہے۔ Sanity check سوال کا جواب دیتا ہے "کیا اس تبدیلی نے فعالیت X کو توڑا؟"، جبکہ Smoke Test جواب دیتا ہے "کیا بلڈ بنیادی طور پر کام کر رہا ہے؟"۔

کیا Smoke Test کو آٹومیٹ کرنا ضروری ہے؟

ہاں، Smoke Test کو آٹومیٹ کرنا بار بار ریلیز والے پروجیکٹس کے لیے لازمی عمل ہے۔ آٹومیشن جانچوں کی مستقل مزاجی اور عملدرآمد کی رفتار کو یقینی بناتا ہے۔ دستی Smoke Test صرف پروجیکٹ کے ابتدائی مراحل میں جائز ہے جب بلڈ کی تعداد فی ہفتہ 2–3 سے زیادہ نہ ہو۔

اگر Smoke Test ناکام ہو جائے تو کیا کریں؟

بلڈ کو غیر مستحکم قرار دیا جاتا ہے اور مزید ٹیسٹنگ کے لیے نہیں بھیجا جاتا۔ ڈیولپر کو Smoke Test کی ناکامی کے لاگ کے ساتھ اطلاع ملتی ہے۔ مسئلہ حل کرنے کے بعد، ایک نیا بلڈ بنایا جاتا ہے اور Smoke Test دوبارہ چلایا جاتا ہے۔ بلاک کرنے والا نقص ٹریکر میں ریکارڈ کیا جاتا ہے۔

Smoke Test کو کتنی بار اپ ڈیٹ کرنا چاہیے؟

Smoke Test کو ہر بار اپ ڈیٹ کیا جاتا ہے جب صارف کا اہم راستہ بدلتا ہے۔ اگر کوئی نیا لازمی اسکرین شامل کیا جاتا ہے (مثلاً آن بورڈنگ)، تو اسے Smoke Test میں شامل کیا جانا چاہیے۔ جانچوں کی مطابقت برقرار رکھنے کے لیے ہر سپرنٹ Smoke Test سیٹ کا جائزہ لینے کی سفارش کی جاتی ہے۔

خلاصہ

  • Smoke Test — ہر بلڈ کے بعد چلائے جانے والے ایپلیکیشن کے اہم راستے کے کم سے کم جانچوں کا سیٹ۔
  • اہم جانچیں — ایپ لانچ، تصدیق، مواد لوڈنگ اور اہم اسکرینوں پر نیویگیشن۔
  • ریگریشن سے فرق — Smoke Test 5–10% منظرناموں کو کور کرتا ہے اور 5–15 منٹ لیتا ہے، گھنٹے نہیں۔
  • اوزار — iOS کے لیے XCUITest، Android کے لیے Espresso، React Native کے لیے Detox۔
  • آٹومیشن Smoke Test Fastlane، GitHub Actions یا Bitrise کے ذریعے CI/CD میں ضم ہوتا ہے۔
  • Smoke Test ریگریشن ٹیسٹنگ سے پہلے چلتا ہے اور 30% تک غیر مستحکم بلڈز کو فلٹر کرتا ہے۔
  • مطابقت برقرار رکھنے کے لیے ہر سپرنٹ Smoke Test کی ساخت کا جائزہ لینے کی سفارش کی جاتی ہے۔

ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے

IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔

پروجیکٹ پر بحث کریں

مزید پڑھیں