A First Look at the Self-Admitted Technical Debt in Test Code: Taxonomy and Detection
यह शोध पत्र टेस्ट कोड में स्व-स्वीकृत तकनीकी ऋण (SATD) के लिए एक नया 11-श्रेणी वाला वर्गीकरण स्थापित करने हेतु 1,000 जावा परियोजनाओं के 50,000 कमेंट्स का एक बड़े पैमाने पर मैनुअल विश्लेषण प्रस्तुत करता है और यह प्रदर्शित करता है कि न तो मौजूदा डिटेक्शन टूल्स और न ही वर्तमान लार्ज लैंग्वेज मॉडल्स विश्वसनीय रूप से ऐसे ऋण की पहचान कर सकते हैं।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
सॉफ्टवेयर कभी वास्तव में समाप्त नहीं होता। प्रोग्राम जारी होने के बाद भी, डेवलपर्स को त्रुटियों को ठीक करने, नई सुविधाएँ जोड़ने और बदलती जरूरतों के अनुकूल होने के लिए लगातार उस पर वापस आना पड़ता है। इस निरंतर कार्य को रखरखाव (maintenance) कहा जाता है, और इसमें अक्सर सॉफ्टवेयर के प्रारंभिक निर्माण की तुलना में अधिक प्रयास की आवश्यकता होती है। इस कार्य को प्रबंधनीय रखने के लिए, प्रोग्रामर कभी-कभी अपने कोड में नोट्स छोड़ देते हैं, जिसमें वे स्वीकार करते हैं कि कोई विशेष भाग अव्यवस्थित, अस्थायी या पूरी तरह से सही नहीं है। वे यह कहते हुए एक टिप्पणी लिख सकते हैं, "यह एक जुगाड़ (hack) है," या "इसे बाद में ठीक करें।" सॉफ्टवेयर इंजीनियरिंग की दुनिया में, इन ईमानदार स्वीकारोक्तियों को 'स्व-स्वीकृत तकनीकी ऋण' (self-admitted technical debt) के रूप में जाना जाता है। यह एक डेवलपर द्वारा यह कहने जैसा है कि, "मैं जानता हूँ कि यह करने का सबसे अच्छा तरीका नहीं है, लेकिन हमें इसे अभी करना था।" जबकि शोधकर्ताओं ने लंबे समय से प्रोग्राम चलाने वाले मुख्य कोड में इन नोट्स का अध्ययन किया है, उन्होंने परीक्षण (test) के लिए उपयोग किए जाने वाले कोड में पाए जाने वाले नोट्स की काफी हद तक अनदेखी की है। यह एक महत्वपूर्ण चूक है, क्योंकि यदि परीक्षण स्वयं दोषपूर्ण या खराब तरीके से लिखे गए हैं, तो पूरा सॉफ्टवेयर सिस्टम अविश्वसनीय हो जाता है।
यूनिवर्सिटी ऑफ मैनिटोबा के शोधकर्ताओं की एक टीम ने इस छिपे हुए ऋण को समझने के लिए हाथ बढ़ाया। उन्होंने जावा (Java) में लिखे गए एक विशिष्ट प्रकार के सॉफ्टवेयर पर ध्यान केंद्रित किया, जो जटिल एप्लिकेशन बनाने के लिए व्यापक रूप से उपयोग की जाने वाली भाषा है। एक स्पष्ट तस्वीर पाने के लिए, उन्होंने एक हजार अलग-अलग ओपन-सोर्स प्रोजेक्ट्स से दस लाख से अधिक टिप्पणियों का एक विशाल संग्रह एकत्र किया। इस विशाल पूल से, उन्होंने पचास हजार टिप्पणियों को हाथ से जांचने के लिए यादृच्छिक रूप से चुना। यह मैन्युअल समीक्षा एक कठिन कार्य था, जिसमें शोधकर्ताओं को प्रत्येक नोट को पढ़ना था और यह तय करना था कि क्या वह समस्या की वास्तविक स्वीकृति है या केवल एक मानक स्पष्टीकरण है। उन टिप्पणियों को फ़िल्टर करने के बाद जो प्रासंगिक नहीं थीं या जो किसी एक प्रोजेक्ट से आई थीं जिससे डेटा पक्षपाती हो सकता था, उन्होंने 615 ऐसी टिप्पणियों की पहचान की जो टेस्ट कोड में वास्तविक तकनीकी ऋण के उदाहरण थे।
शोधकर्ताओं ने पाया कि टेस्ट कोड में इन ऋणों की प्रकृति मुख्य एप्लिकेशन कोड में मिलने वाले ऋणों से काफी भिन्न है। उन्होंने इन 615 उदाहरणों को ग्यारह विशिष्ट श्रेणियों में वर्गीकृत किया। इनमें से कुछ परिचित थे, जैसे कि खराब डिज़ाइन या लुप्त दस्तावेज़ीकरण (documentation) के बारे में नोट्स। हालांकि, चार श्रेणियां पूरी तरह से नई और परीक्षण की दुनिया के लिए विशिष्ट थीं। इनमें "सीमित परीक्षण" (limited tests) शामिल थे, जहाँ एक डेवलपर स्वीकार करता है कि परीक्षण केवल समस्या के एक बहुत छोटे, गैर-प्रतिनिधिक हिस्से की जाँच करता है; "स्किप टेस्ट" (skip tests), जहाँ एक परीक्षण को स्पष्ट रूप से बंद कर दिया जाता है क्योंकि वह वर्तमान वातावरण में नहीं चल सकता; "ऑन-होल्ड" (on-hold), जहाँ एक परीक्षण किसी बाहरी टूल या सेवा के उपलब्ध होने की प्रतीक्षा करता है; और "अनिश्चितता" (uncertainty), जहाँ डेवलपर अनिश्चित है कि परीक्षण सही भी है या नहीं। इस वर्गीकरण ने खुलासा किया कि टेस्ट कोड के अपने अनूठे बोझ होते हैं, जो अक्सर सॉफ्टवेयर बनाने के बजाय सॉफ्टवेयर के व्यवहार को मान्य करने की विशिष्ट चुनौतियों से संबंधित होते हैं।
इन ऋणों के स्वरूप को मैप करने के बाद, टीम ने एक दूसरा, अधिक व्यावहारिक प्रश्न पूछा: क्या कंप्यूटर उन्हें स्वचालित रूप से खोज सकते हैं? उन्होंने नियमित सोर्स कोड में इन नोट्स को खोजने के लिए डिज़ाइन किए गए सात मौजूदा टूल्स का परीक्षण किया। उन्होंने ओपन-सोर्स मॉडल और प्रमुख प्रौद्योगिकी कंपनियों के शक्तिशाली, प्रोप्रायटरी (proprietary) सिस्टम सहित आर्टिफिशियल इंटेलिजेंस मॉडल्स की एक श्रृंखला का भी परीक्षण किया। परिणाम आश्चर्यजनक थे। मौजूदा टूल्स, जो "TODO" या "FIXME" जैसे विशिष्ट कीवर्ड्स को खोजने पर निर्भर करते हैं, पारंपरिक तरीकों में सबसे अच्छा प्रदर्शन करते थे, लेकिन फिर भी वे वास्तविक ऋणों के एक तिहाई से अधिक को मिस कर देते थे। वे कुछ खोजने में तो सही थे, लेकिन वे कई वास्तविक समस्याओं को खोजने में विफल रहे।
आर्टिफिशियल इंटेलिजेंस मॉडल्स अलग-अलग तरीकों से और भी बदतर रहे। ओपन-सोर्स मॉडल ऋणों को खोजने में संघर्ष करते थे, अक्सर तब तक पहचानने में विफल रहते थे जब तक कि नोट्स में बहुत स्पष्ट कीवर्ड न हों। जब उन्होंने कुछ पाया भी, तो वे अक्सर गलत थे। प्रोप्रायटरी मॉडल्स, जिन्हें आम तौर पर अधिक उन्नत माना जाता है, में इसके विपरीत समस्या थी। उन्होंने लगभग हर एक ऋण को खोज लिया, लेकिन उन्होंने सैकड़ों हानिरहित टिप्पणियों को भी समस्या के रूप में चिह्नित किया। वे समस्याओं को खोजने के लिए इतने उत्सुक थे कि उन्होंने सामान्य स्पष्टीकरणों को विफलता की स्वीकृति समझ लिया। अंत में, न तो पारंपरिक टूल्स और न ही सबसे उन्नत एआई सिस्टम टेस्ट कोड में इन ऋणों को विश्वसनीय रूप से पहचान सके।
अध्ययन निष्कर्ष निकालता है कि टेस्ट कोड में डेवलपर्स द्वारा समस्याओं को लिखने का तरीका मुख्य कोड में लिखने के तरीके से मौलिक रूप से भिन्न है। टेस्ट फाइलों में नोट्स अक्सर परीक्षण प्रक्रिया से संबंधित भाषा का उपयोग करते हैं, जैसे कि यह उल्लेख करना कि एक परीक्षण "डिसेबल" (disabled) या "स्किप्ड" (skipped) है, जिसे मानक टूल्स और एआई मॉडल ऋण के संकेत के रूप में नहीं पहचानते हैं। शोधकर्ताओं ने पाया कि वर्तमान तरीके इस जटिलता को संभालने के लिए अभी तैयार नहीं हैं। उन्होंने भविष्य के शोधकर्ताओं को बेहतर डिटेक्शन टूल्स बनाने में मदद करने के लिए एक नया डेटासेट और इन ऋण प्रकारों का एक विस्तृत मानचित्र बनाया है। तब तक, टेस्ट कोड में इन छिपे हुए दोषों को खोजने और ठीक करने का कार्य मानवीय ध्यान की आवश्यकता वाला काम बना रहेगा।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।