Smoke Test (سموک ٹیسٹنگ) جانچوں کا ایک کم سے کم سیٹ ہے جو موبائل ایپلیکیشن بلڈ کے بعد اس بات کی تصدیق کے لیے کیا جاتا ہے کہ اہم افعال کام کر رہے ہیں۔ Smoke Test مکمل ریگریشن سائیکل چلائے بغیر غیر مستحکم بلڈز کو فوری طور پر مسترد کرنے کی اجازت دیتا ہے۔ Google Testing Blog (2024) کے مطابق، Smoke Test ڈیولپر کے لیے فیڈبیک وقت کو 2–3 گھنٹے سے کم کرکے 10–15 منٹ کر دیتا ہے۔ Smoke Test CI/CD پائپ لائن میں معیار کا پہلا فلٹر ہے جو ٹوٹے ہوئے بلڈز کو اگلے مرحلے تک پہنچنے سے روکتا ہے۔
اہم نکات
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 فعالیت کا 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 کولڈ اسٹارٹ چیک کرتا ہے: انسٹال → کھولیں → پہلی اسکرین دکھائیں۔ اگر ایپ لانچ پر کریش ہوتی ہے، تو مزید ٹیسٹنگ بے معنی ہے۔ XCUITest اور Espresso 2–3 لائنوں میں لانچ چیک کو آٹومیٹ کرنے کی اجازت دیتے ہیں۔ لانچ آرگومنٹ `-AppleLanguages (ru)` اسٹارٹ اپ پر لوکلائزیشن کی تصدیق میں مدد کرتا ہے۔
تصدیق — دوسرا اہم منظرنامہ۔ Smoke Test کو تصدیق کرنی چاہیے کہ لاگ ان فارم ظاہر ہوتا ہے، ان پٹ فیلڈز ٹچ پر ردعمل دیتے ہیں، لاگ ان بٹن درخواست بھیجتا ہے اور کامیاب تصدیق کے بعد ایپلیکیشن مرکزی اسکرین پر جاتی ہے۔ تصدیق کی خرابی دیگر تمام افعال تک رسائی کو روکتی ہے، اس لیے اس کی جانچ کم سے کم سیٹ میں شامل ہے۔ ٹوکن ریفریش — OAuth 2.0 استعمال کرنے والی ایپلیکیشنز کے لیے اضافی جانچ۔
اہم مواد کی لوڈنگ — تیسرا Smoke Test۔ ایپلیکیشن کی مرکزی اسکرین یا فیڈ لوڈ ہونی چاہیے اور ڈیٹا دکھانا چاہیے۔ اگر API جواب نہیں دیتی یا جواب کی پارسنگ ٹوٹ گئی ہے، تو صارف کو خالی اسکرین نظر آتی ہے۔ Smoke Test میں نیٹ ورک کی جانچ میں مرکزی اینڈپوائنٹ پر ایک بنیادی GET درخواست اور جواب کی متوقع ساخت کی تصدیق شامل ہے۔ نیویگیشن — چوتھا منظرنامہ۔ Smoke Test ایپلیکیشن کی مرکزی اسکرینوں پر گھومتا ہے: ہوم → تلاش → پروفائل → ترتیبات۔ ٹیب بار اور سائڈ مینو نیویگیشن مسائل کے عام ذرائع ہیں جنہیں 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 منٹ سے زیادہ لیتا ہے، تو اسے بہتر بنانے کی ضرورت ہے: غیر ضروری جانچیں ہٹائیں یا عملدرآمد کو متوازی کریں۔
# 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
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 کو سورس کوڈ تک براہ راست رسائی کے بغیر ایپلیکیشن کی حالت کی تصدیق کرنے کی اجازت دیتی ہے۔
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 کے متوازی عملدرآمد کی حمایت کرتا ہے۔
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 عنصر اس وقت میں ظاہر نہیں ہوتا، تو ایپلیکیشن صحیح طریقے سے کام نہیں کر رہی۔
اکثر پوچھے گئے سوالات
بہترین تعداد 5 سے 15 ٹیسٹ فی ماڈیول ہے۔ Smoke Test کو صارف کے اہم راستے کو کور کرنا چاہیے لیکن پوری فعالیت کو کور کرنے کی کوشش نہیں کرنی چاہیے۔ معیار — اگر تمام Smoke Test پاس ہو جائیں، تو ایپلیکیشن کو مزید ٹیسٹنگ کے لیے QA ماحول میں کھولا جا سکتا ہے۔
Smoke Test بلڈ استحکام کی جانچ کرتا ہے اور ہر بلڈ پر چلتا ہے۔ Sanity check ٹیسٹوں کا ایک تنگ سیٹ ہے جو مخصوص تبدیلیوں کے بعد کیا جاتا ہے۔ Sanity check سوال کا جواب دیتا ہے "کیا اس تبدیلی نے فعالیت X کو توڑا؟"، جبکہ Smoke Test جواب دیتا ہے "کیا بلڈ بنیادی طور پر کام کر رہا ہے؟"۔
ہاں، Smoke Test کو آٹومیٹ کرنا بار بار ریلیز والے پروجیکٹس کے لیے لازمی عمل ہے۔ آٹومیشن جانچوں کی مستقل مزاجی اور عملدرآمد کی رفتار کو یقینی بناتا ہے۔ دستی Smoke Test صرف پروجیکٹ کے ابتدائی مراحل میں جائز ہے جب بلڈ کی تعداد فی ہفتہ 2–3 سے زیادہ نہ ہو۔
بلڈ کو غیر مستحکم قرار دیا جاتا ہے اور مزید ٹیسٹنگ کے لیے نہیں بھیجا جاتا۔ ڈیولپر کو Smoke Test کی ناکامی کے لاگ کے ساتھ اطلاع ملتی ہے۔ مسئلہ حل کرنے کے بعد، ایک نیا بلڈ بنایا جاتا ہے اور Smoke Test دوبارہ چلایا جاتا ہے۔ بلاک کرنے والا نقص ٹریکر میں ریکارڈ کیا جاتا ہے۔
Smoke Test کو ہر بار اپ ڈیٹ کیا جاتا ہے جب صارف کا اہم راستہ بدلتا ہے۔ اگر کوئی نیا لازمی اسکرین شامل کیا جاتا ہے (مثلاً آن بورڈنگ)، تو اسے Smoke Test میں شامل کیا جانا چاہیے۔ جانچوں کی مطابقت برقرار رکھنے کے لیے ہر سپرنٹ Smoke Test سیٹ کا جائزہ لینے کی سفارش کی جاتی ہے۔
خلاصہ
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں