موبائل ڈیولپمنٹ میں ریگریشن ٹیسٹنگ — یہ کیا ہے، اقسام اور کیسے کی جاتی ہے

ریگریشن ٹیسٹنگ کیا ہے؟

ریگریشن ٹیسٹنگ ایک قسم کی جانچ ہے جس کا مقصد یہ تصدیق کرنا ہے کہ کوڈ کی تبدیلیوں نے موجودہ فعالیت کو نہیں توڑا۔ اصطلاح «ریگریشن» کا مطلب بدتر حالت کی طرف واپسی ہے — جب کوئی فنکشن جو پچھلے ورژن میں کام کرتا تھا نئے ورژن میں کام کرنا بند کر دیتا ہے۔ ریگریشن ٹیسٹ ہر ڈیولپمنٹ سائیکل میں بار بار انجام دیے جاتے ہیں، جو انہیں نئی خصوصیت کے ٹیسٹوں سے ممتاز کرتا ہے جو ایک بار لکھے جاتے ہیں۔

ریگریشن ٹیسٹنگ کی ضرورت جھڑی والی تبدیلیوں کے اثر سے پیدا ہوتی ہے: ایک ماڈیول میں بگ کو ٹھیک کرنے سے مسئلہ حل ہو سکتا ہے لیکن ملحقہ فعالیت ٹوٹ سکتی ہے جو اس پر منحصر تھی۔ مثال کے طور پر، یوزر ریپوزٹری میں SQL سوال کو تبدیل کرنے سے تصدیق تیز ہو سکتی ہے لیکن ڈیٹا ایکسپورٹ ٹوٹ سکتا ہے جو اسی سوال کو استعمال کرتا تھا۔ ڈیٹا ایکسپورٹ پر ریگریشن ٹیسٹ ریلیز سے پہلے اس خلاف ورزی کو پکڑ لے گا۔

CISQ 2023 رپورٹ کے مطابق، پروڈکشن میں پائے جانے والے ریگریشن نقص کو ٹھیک کرنے کی لاگت خودکار ریگریشن رن مرحلے کے مقابلے میں 15 گنا زیادہ ہے۔ Capgemini World Quality Report کے مطابق، خودکار ریگریشن ٹیسٹنگ میں سرمایہ کاری کرنے والی کمپنیاں نفاذ کے ایک سال کے اندر ریلیز میں ریگریشن نقائص کے حصے کو 25% سے 5% تک کم کر دیتی ہیں۔

ریگریشن ٹیسٹنگ کی اقسام

ریگریشن ٹیسٹنگ کے کئی طریقے ہیں جو دائرہ کار اور ٹیسٹ کے انتخاب کے معیار میں مختلف ہیں۔ طریقے کا انتخاب پروجیکٹ کے سائز، تبدیلیوں کی تعدد اور CI پائپ لائن میں دستیاب وقت پر منحصر ہے۔ ذیل میں ان کی خصوصیات کے ساتھ ریگریشن ٹیسٹنگ کی اہم اقسام ہیں۔

مکمل ریگریشن ٹیسٹنگ

مکمل ریگریشن رن بغیر کسی استثنا کے پروجیکٹ کے تمام خودکار ٹیسٹ انجام دیتا ہے۔ یہ طریقہ زیادہ سے زیادہ اعتماد دیتا ہے لیکن اس کے لیے اہم کمپیوٹنگ وسائل اور وقت درکار ہوتا ہے۔ مکمل رن بڑی ریلیز سے پہلے کیا جاتا ہے — ہر 2–4 ہفتوں میں۔ 5000 ٹیسٹ والی ایپلیکیشن کے لیے، مکمل رن میں بنیادی ڈھانچے کے لحاظ سے 2 سے 6 گھنٹے لگتے ہیں۔

انتخابی ریگریشن ٹیسٹنگ

انتخابی طریقہ صرف تبدیل شدہ ماڈیولز سے متعلق ٹیسٹ چلاتا ہے۔ تعلق کا تعین کرنے کے لیے کوڈ کی سطح پر انحصار کا تجزیہ استعمال کیا جاتا ہے: اگر UserRepository کلاس تبدیل کی جاتی ہے، تو UserRepository پر براہ راست یا عبوری طور پر منحصر ٹیسٹ چلائے جاتے ہیں۔ Jacoco، Android Test Coverage اور Xcode Code Coverage جیسے اوزار درست انتخاب کے لیے کوریج کے نقشے فراہم کرتے ہیں۔ انتخابی رن ہر پل ریکویسٹ پر کیا جاتا ہے اور 5–15 منٹ لگتا ہے۔

خطرے پر مبنی ریگریشن

خطرے پر مبنی ریگریشن ٹیسٹوں کو فعالیت کی اہمیت اور ٹوٹنے کے امکان کے مطابق درجہ بندی کرتی ہے۔ اہم افعال — ادائیگی، تصدیق، مطابقت پذیری — ہر کوڈ تبدیلی پر جانچے جاتے ہیں۔ معاون افعال — “ہمارے بارے میں” اسکرین، اینیمیشنز — صرف ریلیز سے پہلے جانچے جاتے ہیں۔ درجہ بندی کا پروڈکشن واقعات کے اعداد و شمار کی بنیاد پر سہ ماہی جائزہ لیا جاتا ہے۔

ریگریشن ٹیسٹنگ اور دوبارہ ٹیسٹ میں فرق

ریگریشن ٹیسٹنگ اور دوبارہ ٹیسٹ کے تصورات اکثر الجھ جاتے ہیں، اگرچہ یہ مختلف عمل ہیں۔ دوبارہ ٹیسٹ نقص کی اصلاح کے بعد، پہلے ناکام ہونے والے کسی مخصوص ٹیسٹ کو دوبارہ چلانا ہے۔ دوبارہ ٹیسٹ کا مقصد یہ تصدیق کرنا ہے کہ اصلاح کام کرتی ہے: بگ دوبارہ پیدا نہیں ہوتا۔ دوبارہ ٹیسٹ ایک بار کیا جاتا ہے، اصلاح اور ڈیولپر کی اصلاح کی تصدیق کے فوراً بعد۔

ریگریشن ٹیسٹنگ موجودہ فعالیت پر ٹیسٹ چلانا ہے جسے تبدیل نہیں کیا گیا۔ مقصد یہ یقینی بنانا ہے کہ ایک نقص کو ٹھیک کرنے سے کہیں اور نیا نقص پیدا نہیں ہوا۔ ریگریشن ٹیسٹ ہر ڈیولپمنٹ سائیکل میں بار بار چلائے جاتے ہیں، اس سے قطع نظر کہ کون سے مخصوص بگ ٹھیک کیے گئے۔ بنیادی فرق: دوبارہ ٹیسٹ اصلاح کی تصدیق کرتا ہے، ریگریشن اصلاح کے نتائج کی تصدیق کرتا ہے۔

CI/CD پائپ لائن میں، دونوں عمل ترتیب وار انجام پاتے ہیں۔ پل ریکویسٹ کو ضم کرنے کے بعد، مخصوص بگ کا دوبارہ ٹیسٹ چلایا جاتا ہے، اس کے بعد مکمل یا انتخابی ریگریشن رن کیا جاتا ہے۔ SmartBear (2022) کے مطابق، ان عملوں کو الگ کرنے سے ناکام CI رنز کی تشخیص کا وقت 30% کم ہو جاتا ہے، کیونکہ ٹیم فوراً دیکھ لیتی ہے کہ کون سے نقائص ریگریشن سے متعلق ہیں اور کون سے غیر کام کرنے والی اصلاحات سے۔

ریگریشن ٹیسٹنگ کا آٹومیشن

ریگریشن ٹیسٹنگ کا آٹومیشن جدید موبائل پروجیکٹس کے لیے ایک اہم کامیابی کا عنصر ہے۔ دستی ریگریشن ٹیسٹنگ پیمانہ پذیر نہیں ہے: 200 ٹیسٹ کے سوٹ کے ساتھ، ایک رن کے لیے QA انجینئر کے 2–3 کام کے دن درکار ہوتے ہیں، جو روزانہ رن کو ناممکن بناتا ہے۔ خودکار ریگریشن ٹیسٹ انسانی مداخلت کے بغیر 10–60 منٹ میں چلتے ہیں، جس سے انہیں ہر commit یا پل ریکویسٹ پر چلایا جا سکتا ہے۔

• یونٹ ٹیسٹ — ریگریشن سوٹ کی بنیاد (70%)۔ سیکنڈوں میں چلتے ہیں، ایمولیٹر کی ضرورت نہیں ہوتی، اور ٹوٹے ہوئے کلاس کی درست نشاندہی کرتے ہیں۔
• انٹیگریشن ٹیسٹ — دوسرا درجہ (20%)۔ کنٹرول شدہ انحصار کے ساتھ نیٹ ورک پرت، ڈیٹا بیس اور سسٹم سروسز کو چیک کرتے ہیں۔
• UI ٹیسٹ اور E2E ٹیسٹ — پیرامڈ کی چوٹی (10%)۔ اہم صارف کے منظرناموں کا احاطہ کرتے ہیں: رجسٹریشن، ادائیگی، مطابقت پذیری۔

ریگریشن سوٹ کو اپ ڈیٹ رکھنے کے لیے ٹیسٹ اینالیٹکس استعمال کیا جاتا ہے: Allure، ReportPortal اور Xray جیسے اوزار ہر ٹیسٹ کے پاس کی شرح، دورانیہ اور استحکام کو ٹریک کرتے ہیں۔ جن ٹیسٹوں کا استحکام 90% سے نیچے گر جاتا ہے (اکثر ضروریات میں تبدیلی کی وجہ سے ٹوٹ جاتے ہیں)، انہیں لیگیسی کے طور پر نشان زد کیا جاتا ہے اور جائزے کے لیے مالک کو سونپا جاتا ہے۔

ریگریشن ٹیسٹ سیٹ اپ کی مثال

آئیے JUnit 5 لائبریری اور Espresso کا استعمال کرتے ہوئے Android پر ایک خودکار ریگریشن ٹیسٹ کے سیٹ اپ پر نظر ڈالتے ہیں۔ مثال انتخابی ریگریشن کو ظاہر کرتی ہے — ٹیسٹ تصدیق کرتا ہے کہ یوزر ریپوزٹری کو ری فیکٹر کرنے کے بعد پروفائل اسکرین نہیں ٹوٹی۔ iOS کے لیے، اسی منطق کے ساتھ XCTest استعمال کیا جاتا ہے — ایک اہم منظرنامے پر بار بار ٹیسٹ۔

Android: پروفائل ریگریشن ٹیسٹ

ٹیسٹ سرور کو ایمولیٹ کرنے کے لیے MockWebServer استعمال کرتا ہے اور مکمل راستہ چیک کرتا ہے: یوزر ڈیٹا لوڈ کرنا، پروفائل اسکرین پر ڈسپلے کرنا، اور سرور دستیاب نہ ہونے پر خرابی سے نمٹنا۔ ایسے ٹیسٹ ریگریشن سوٹ میں شامل کیے جاتے ہیں اور ماڈیول-پروفائل میں ہر تبدیلی پر چلائے جاتے ہیں۔

@RunWith(AndroidJUnit4::class)
class ProfileRegressionTest {

    @get:Rule
    val composeRule = createComposeRule()

    @Test
    fun profileScreen_rendersCorrectly() {
        val user = User(id = 1, name = "Alice", email = "alice@test.com")
        composeRule.setContent {
            ProfileScreen(user)
        }
        composeRule.onNodeWithText("Alice").assertIsDisplayed()
        composeRule.onNodeWithText("alice@test.com").assertIsDisplayed()
    }

    @Test
    fun profileScreen_handlesNetworkError() {
        setNetworkError()
        composeRule.onNodeWithText("لوڈ کرنے میں خرابی").assertIsDisplayed()
    }
}

iOS: XCTest کے ساتھ ریگریشن ٹیسٹ

iOS کے لیے، ریگریشن ٹیسٹ API سے ڈیٹا حاصل کرنے کے بعد UI اپ ڈیٹ کی غیر متزامن تصدیق کے لیے XCTestExpectation استعمال کرتا ہے۔ ٹیسٹ نیٹ ورک کے جواب کی نقل کرتا ہے اور تصدیق کرتا ہے کہ UI عناصر صحیح طریقے سے اپ ڈیٹ ہوئے۔

class ProfileRegressionTests: XCTestCase {
    func testProfileScreen_rendersCorrectly() {
        let viewModel = ProfileViewModel(userId: 1)
        let view = ProfileView(viewModel: viewModel)
        viewModel.loadProfile()

        let expectation = expectation(description: "profile loaded")
        viewModel.onProfileLoaded = {
            XCTAssertEqual(viewModel.userName, "Alice")
            XCTAssertEqual(viewModel.userEmail, "alice@test.com")
            expectation.fulfill()
        }
        waitForExpectations(timeout: 3.0)
    }
}

ریگریشن سوٹ بنانے کی حکمت عملی

ایک مؤثر ریگریشن سوٹ بنانا نقائص اور کوڈ تبدیلی کے اعداد و شمار پر مبنی ایک تکراری عمل ہے۔ ابتدائی حکمت عملی — تمام موجودہ ٹیسٹوں کو ریگریشن سوٹ میں شامل کرنا اور ہر ریلیز سے پہلے مکمل رن چلانا ہے۔ جیسے جیسے ٹیسٹ کی بنیاد بڑھتی ہے (2000 سے زیادہ ٹیسٹ)، مکمل رن بہت لمبا ہو جاتا ہے اور انتخابی طریقہ کار کی ضرورت ہوتی ہے۔

دوسرا مرحلہ — انحصار تجزیہ کے اوزار کا نفاذ: Android کے لیے Jacoco، iOS کے لیے Xcode Test Plan۔ یہ اوزار «ٹیسٹ — کلاس — طریقہ» کا نقشہ بناتے ہیں اور یہ تعین کرنے کی اجازت دیتے ہیں کہ کسی مخصوص تبدیلی سے کون سے ٹیسٹ متاثر ہوتے ہیں۔ Spotify Engineering (2022) کے مطابق، کوریج تجزیہ پر مبنی انتخابی رن 95% ریگریشن پتہ لگانے کی تاثیر برقرار رکھتے ہوئے عملدرآمد کا وقت 60–80% کم کرتا ہے۔

تیسرا مرحلہ — مسلسل نگرانی اور اصلاح۔ جو ٹیسٹ 6 ماہ میں ناکام نہیں ہوئے، انہیں کم ترجیحی سوٹ میں منتقل کیا جاتا ہے۔ جو ٹیسٹ مہینے میں ایک بار سے زیادہ ناکام ہوتے ہیں، وہ جائزے کے لیے امیدوار ہیں: یا تو وہ حقیقی مسائل کو پکڑتے ہیں (فکس کی ضرورت ہے) یا وہ بہت نازک ہیں (استحکام کی ضرورت ہے)۔ ریگریشن سوٹ کا سہ ماہی جائزہ اس کی تاثیر اور عملدرآمد کی رفتار کو برقرار رکھنے کے لیے معیاری عمل ہے۔