रीग्रेशन — यह क्या है, क्यों होता है और कैसे परीक्षण करें

डेवलपमेंट में रीग्रेशन क्या है

रीग्रेशन वह स्थिति है जब पिछले वर्जन में काम करने वाली कार्यक्षमता बदलाव करने के बाद काम करना बंद कर देती है। बदलाव कुछ भी हो सकता है: बग फिक्स, नई फीचर जोड़ना, रिफैक्टरिंग, लाइब्रेरी अपडेट या कॉन्फ़िगरेशन बदलाव। रीग्रेशन स्थिरता का मुख्य दुश्मन है: हर बदलाव कुछ ऐसा तोड़ने का जोखिम उठाता है जो पहले सत्यापित और जारी किया जा चुका है।

यह शब्द परीक्षण से आया है: रीग्रेशन परीक्षण प्रत्येक बदलाव के बाद मौजूदा परीक्षणों को फिर से चलाने की प्रक्रिया है। यदि पहले पास होने वाला परीक्षण विफल होता है, तो रीग्रेशन हुआ है। व्यापक अर्थ में, रीग्रेशन केवल परीक्षण विफलता नहीं है, बल्कि उपयोगकर्ता या QA द्वारा देखा गया कोई भी व्यवहार गिरावट है। Tricentis State of Testing 2023 के अनुसार, प्रोडक्शन में पाए जाने वाले सभी बगों में 35–45% रीग्रेशन होते हैं।

रीग्रेशन को सामान्य बग से अलग करने वाली चीज़ है समय संदर्भ: एक बग हमेशा से मौजूद रहा हो सकता है, जबकि रीग्रेशन हमेशा किसी बदलाव का परिणाम होता है। यह एक महत्वपूर्ण अंतर है क्योंकि रीग्रेशन का कारण खोजने की शुरुआत यह विश्लेषण करने से होती है कि «काम कर रहा था» और «काम करना बंद कर दिया» के बीच क्या बदला। Git bisect रीग्रेशन पैदा करने वाले कमिट को खोजने का मानक उपकरण है।

रीग्रेशन के प्रकार और उदाहरण

स्थानीय रीग्रेशन — मॉड्यूल A में बदलाव उसी मॉड्यूल A में कार्यक्षमता तोड़ता है। उदाहरण: डेवलपर सॉर्टिंग फंक्शन को फिर से लिखता है और वह खाली ऐरे को सही ढंग से संभालना बंद कर देता है। स्थानीय रीग्रेशन का पता लगाना और ठीक करना सबसे आसान है क्योंकि कारण और प्रभाव पास-पास होते हैं।

दूरस्थ रीग्रेशन — मॉड्यूल A में बदलाव मॉड्यूल B में कार्यक्षमता तोड़ता है, जो कोड द्वारा सीधे कनेक्ट नहीं है लेकिन डेटा या समय से जुड़ा है। उदाहरण: «उपयोगकर्ता» मॉड्यूल में डेटाबेस स्कीमा बदलना «एनालिटिक्स» मॉड्यूल में रिपोर्ट तोड़ता है जो उसी तालिका का उपयोग करता है। दूरस्थ रीग्रेशन सबसे कपटी होते हैं: डेवलपर को संदेह नहीं होता कि उसका बदलाव किसी अन्य मॉड्यूल को प्रभावित करेगा।

साइड-इफेक्ट रीग्रेशन — साइड इफेक्ट (लॉगिंग, कैशिंग, नोटिफिकेशन भेजना) में बदलाव अपेक्षित व्यवहार को तोड़ता है। उदाहरण: डेवलपर गति बढ़ाने के लिए कैशिंग जोड़ता है, लेकिन पुराने कैश के कारण उपयोगकर्ता पुराना डेटा देखते हैं। साइड-इफेक्ट रीग्रेशन को स्वचालित परीक्षणों से पकड़ना मुश्किल है क्योंकि साइड इफेक्ट अक्सर परीक्षणों द्वारा कवर नहीं होते।

प्रदर्शन रीग्रेशन — कोड कार्यात्मक रूप से सही काम करता रहता है लेकिन पहले से धीमा है। उदाहरण: नया एन्क्रिप्शन एल्गोरिदम वही परिणाम देता है, लेकिन निष्पादन समय 2 ms से बढ़कर 200 ms हो गया। प्रदर्शन रीग्रेशन सामान्य यूनिट टेस्ट से नहीं पकड़े जाते — बेंचमार्क और प्रोफाइलिंग की ज़रूरत होती है।

रीग्रेशन क्यों होते हैं

पहला कारण कोड कपलिंग है। मॉड्यूल जितना अधिक एक-दूसरे पर निर्भर होते हैं, उतनी ही अधिक संभावना है कि एक में बदलाव दूसरे में रीग्रेशन पैदा करेगा। क्लासिक एंटी-पैटर्न: गॉड ऑब्जेक्ट (एक ऑब्जेक्ट जो सब कुछ करता है), शॉटगन सर्जरी (एक जगह बदलाव के लिए दर्जनों जगहों पर संपादन की आवश्यकता), सर्कुलर डिपेंडेंसी। कपलिंग कम करना आर्किटेक्चर का मामला है: SOLID सिद्धांत, डिपेंडेंसी इंजेक्शन, हेक्सागोनल आर्किटेक्चर।

दूसरा कारण बदली गई कार्यक्षमता के लिए परीक्षणों की कमी है। यदि कोड परीक्षणों द्वारा कवर नहीं है, तो डेवलपर को रीग्रेशन के बारे में केवल QA या उपयोगकर्ताओं से पता चलता है। Google Testing Blog के अनुसार, >75% परीक्षण कवरेज वाले प्रोजेक्ट्स में <25% कवरेज वाले प्रोजेक्ट्स की तुलना में 5 गुना कम रीग्रेशन होते हैं। TDD (टेस्ट-ड्रिवन डेवलपमेंट) सुनिश्चित करता है कि परीक्षण कोड से पहले लिखे जाएँ, न कि «जब समय मिले»।

तीसरा कारण मानवीय कारक है। डेवलपर को संबंधित कार्यक्षमता के बारे में पता नहीं होता, वह सभी निर्भरताओं को नहीं समझता या बस जल्दी में होता है। कारण कोडबेस ज्ञान साझाकरण की कमी है। समाधान: अन्य मॉड्यूल के डेवलपर्स के साथ कोड रिव्यू, पेयर प्रोग्रामिंग, आर्किटेक्चर दस्तावेज़ीकरण। प्रोजेक्ट का बस फ़ैक्टर दस्तावेज़ीकृत आर्किटेक्चरल निर्णयों की संख्या के व्युत्क्रमानुपाती होता है।

रीग्रेशन परीक्षण और इसकी भूमिका

रीग्रेशन परीक्षण प्रत्येक बदलाव के बाद मौजूदा परीक्षणों को फिर से चलाने की प्रक्रिया है ताकि यह सत्यापित किया जा सके कि पुरानी कार्यक्षमता नहीं टूटी है। यह गारंटी देने का एकमात्र तरीका है कि नए बदलाव ने मौजूदा कोड को बाधित नहीं किया है। रीग्रेशन परीक्षण के बिना, हर रिलीज़ एक लॉटरी है: डेवलपर उम्मीद करता है कि उसने कुछ नहीं तोड़ा लेकिन इसकी पुष्टि नहीं कर सकता।

मैनुअल रीग्रेशन परीक्षण सबसे महँगा और अप्रभावी दृष्टिकोण है। जैसे-जैसे प्रोजेक्ट बढ़ता है, रीग्रेशन परीक्षण परिदृश्यों की संख्या रैखिक रूप से बढ़ती है, जबकि मैनुअल निष्पादन समय तेज़ी से बढ़ता है। 2–3 साल के डेवलपमेंट के बाद, मैनुअल रीग्रेशन में 2–3 सप्ताह लग सकते हैं, जिससे बार-बार रिलीज़ असंभव हो जाती है। एकमात्र समाधान ऑटोमेशन है।

स्वचालित रीग्रेशन परीक्षण परीक्षण पिरामिड के अनुसार स्तरों में विभाजित होता है:

• यूनिट टेस्ट — तेज़, अलग-थलग, व्यक्तिगत फंक्शन और मेथड को कवर करते हैं
• इंटीग्रेशन टेस्ट — मॉड्यूल, डेटाबेस, बाहरी सेवाओं के बीच इंटरैक्शन सत्यापित करते हैं
• E2E टेस्ट — UI या API के माध्यम से पूर्ण उपयोगकर्ता परिदृश्य सत्यापित करते हैं
• स्नैपशॉट टेस्ट — कंपोनेंट के वर्तमान आउटपुट की तुलना संदर्भ से करते हैं

Google Testing Blog के अनुसार, इष्टतम अनुपात 70% यूनिट टेस्ट, 20% इंटीग्रेशन टेस्ट, 10% E2E है। इस अनुपात से विचलन रीग्रेशन परीक्षण की प्रभावशीलता को कम करता है: बहुत अधिक E2E टेस्ट पाइपलाइन को धीमा करते हैं, बहुत कम यूनिट टेस्ट माइक्रो-बग को अनदेखा छोड़ देते हैं।

रीग्रेशन परीक्षण को स्वचालित करने की रणनीतियाँ

पहली रणनीति पूर्ण रीग्रेशन है। प्रोजेक्ट के सभी परीक्षण चलाए जाते हैं। सबसे विश्वसनीय लेकिन सबसे धीमा दृष्टिकोण। छोटे प्रोजेक्ट्स (10,000 परीक्षणों तक, चलने का समय <30 मिनट) के लिए उपयुक्त। बड़े प्रोजेक्ट्स के लिए, पूर्ण रीग्रेशन में घंटे लग सकते हैं, जिससे CI/CD पाइपलाइन अव्यावहारिक हो जाती है।

दूसरी रणनीति चयनात्मक रीग्रेशन है। केवल बदले गए कोड से संबंधित परीक्षण चलाए जाते हैं। संबंध निर्धारित करने के लिए कोड डिपेंडेंसी ग्राफ़ का उपयोग किया जाता है। उपकरण: Bazel (Google), Nx (JavaScript), sbt (Scala)। चयनात्मक रीग्रेशन 60–80% चलने का समय बचाता है लेकिन सटीक डिपेंडेंसी ग्राफ़ निर्माण की आवश्यकता होती है — त्रुटियाँ छूटे हुए रीग्रेशन की ओर ले जाती हैं।

तीसरी रणनीति प्राथमिकता आधारित रीग्रेशन है। सभी परीक्षणों को प्राथमिकता के अनुसार क्रमबद्ध किया जाता है: क्रिटिकल पाथ (सबसे महत्वपूर्ण उपयोगकर्ता परिदृश्य), उच्च जोखिम (बग इतिहास वाला कोड), बदला हुआ कोड (बदलाव से प्रभावित कोड)। पहले सबसे उच्च प्राथमिकता वाले परीक्षण चलाए जाते हैं — यदि वे पास हो जाते हैं, तो डेवलपर को तेज़ फीडबैक मिलता है। समय-सीमित चलाना: क्रिटिकल टेस्ट 10 मिनट में जाँचे जाते हैं, बाकी बैकग्राउंड में चलते हैं।

प्रोजेक्ट में रीग्रेशन को कैसे रोकें

पहला और सबसे महत्वपूर्ण कदम परीक्षण लिखने की संस्कृति है। प्रत्येक बदलाव के साथ एक परीक्षण होना चाहिए जो सत्यापित करे कि बदलाव काम करता है और एक परीक्षण जो सत्यापित करे कि कुछ भी नहीं टूटा। TDD (टेस्ट-ड्रिवन डेवलपमेंट) सबसे अच्छे परिणाम देता है: डेवलपर पहले एक विफल होने वाला परीक्षण लिखता है, फिर कोड जो उसे पास कराता है। यह गारंटी देता है कि परीक्षण कोड से पहले मौजूद है।

दूसरा कदम अनिवार्य परीक्षण निष्पादन के साथ CI/CD पाइपलाइन है। जब तक सभी परीक्षण पास नहीं हो जाते, पुल रिक्वेस्ट को मर्ज नहीं किया जा सकता। आवश्यकता के कारण परीक्षणों को «छोड़ा» नहीं जा सकता — तत्काल बदलाव त्वरित लेकिन अनिवार्य परीक्षण सूट से गुज़रते हैं। Google DevOps Research के अनुसार, अनिवार्य CI/CD वाली टीमों में प्रोडक्शन में 3 गुना कम रीग्रेशन होते हैं।

तीसरा कदम प्रोडक्शन मॉनिटरिंग है। सबसे अच्छे परीक्षण भी रीग्रेशन के खिलाफ 100% सुरक्षा की गारंटी नहीं देते। ऑब्ज़र्वेबिलिटी उपकरण (Sentry, Datadog, New Relic) को प्रत्येक डिप्लॉयमेंट के बाद मुख्य मीट्रिक ट्रैक करनी चाहिए: एरर रेट, लेटेंसी, थ्रूपुट। सीमा पार होने पर स्वचालित रोलबैक एक सुरक्षा जाल है यदि रीग्रेशन प्रोडक्शन में पहुँच भी जाता है।

चौथा कदम रीग्रेशन मानसिकता के साथ कोड रिव्यू है। समीक्षक को पूछना चाहिए: «इस बदलाव से कौन से अन्य मॉड्यूल टूट सकते हैं?». केवल यह जाँचना पर्याप्त नहीं है कि कोड सही है — यह जाँचना ज़रूरी है कि वह संबंधित कार्यक्षमता को बाधित नहीं करेगा। कोड रिव्यू चेकलिस्ट में «संबंधित मॉड्यूल में रीग्रेशन जाँच» आइटम शामिल होना चाहिए।