सॉफ्टवेयर बग

Software Testing प्रवेशद्वार

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

प्रभाव[संपादित करें]

बग, टाइप I और टाइप II त्रुटियों को सक्रिय कर देते हैं जो बदले में व्यापक प्रकार के तरंगित प्रभाव पैदा कर सकते हैं जिसके कारण प्रोग्राम के उपयोगकर्ता को विविध स्तरों की असुविधाओं का सामना करना पड़ सकता है। कुछ बग प्रोग्राम की कार्यक्षमता पर सिर्फ एक हल्का सा प्रभाव डालते हैं और इस तरह एक लंबे समय तक उनका पता ही नहीं चल पाता है। अधिक गंभीर बग प्रोग्राम को क्रैश (नष्ट) या फ्रीज (निष्क्रिय) कर सकते हैं जिसकी वजह से इसकी सेवा बंद हो सकती है। अन्य बग सुरक्षा बग के रूप में समझे जाते हैं, उदाहरण के लिए, ये अनधिकृत विशेषाधिकार प्राप्त करने के क्रम में एक दुर्भावनापूर्ण उपयोगकर्ता को पहुंच संबंधी नियंत्रण का उपयोग करने में सक्षम बना सकते हैं।

बग के परिणाम अत्यंत गंभीर हो सकते हैं। 1980 के दशक में थिरेक-25 विकिरण चिकित्सा मशीन को नियंत्रित करने वाले कोड में मौजूद बग कई मरीजों की मौत के लिए सीधे तौर पर जिम्मेदार थे। 1996 में यूरोपीय अंतरिक्ष एजेंसी का 1 बिलियन अमेरिकी डॉलर का प्रोटोटाइप एरियन-5 रॉकेट ऑन-बोर्ड गाइडेंस कंप्यूटर प्रोग्राम में बग की मौजूदगी के कारण लॉन्च होने के एक मिनट से भी कम समय में नष्ट हो गया था। जून 1994 में एक रॉयल एयर फोर्स चिनूक, मल ऑफ किनटायर में दुर्घटनाग्रस्त हो गया था जिसमें 29 लोग मारे गए थे। शुरुआत में इसे एक पायलट की गलती कहकर खारिज कर दिया गया था लेकिन कंप्यूटर वीकली द्वारा की गयी एक जांच ने पर्याप्त सबूतों का खुलासा किया जो हाउस ऑफ लॉर्ड्स की एक जांच को यह विश्वास दिलाने में कामयाब रहा कि ऐसा विमान के इंजन को नियंत्रित करने वाले कंप्यूटर में मौजूद एक सॉफ्टवेयर बग के कारण हुआ हो सकता है।^[1]

2002 में अमेरिकी वाणिज्य विभाग के नेशनल इंस्टिट्यूट ऑफ स्टैंडर्ड्स एंड टेक्नोलॉजी द्वारा कराये गए एक अध्ययन ने यह निष्कर्ष दिया कि सॉफ्टवेयर बग या एरर इतने व्यापक और हानिकारक हैं कि ये अमेरिकी अर्थव्यवस्था को एक अनुमान के मुताबिक़ सालाना 59 बिलियन डॉलर या सकल घरेलू उत्पाद के लगभग 0.6 प्रतिशत का नुकसान पहुंचाते हैं।^[2]

शब्द-व्युत्पत्ति[संपादित करें]

यह अवधारणा कि सॉफ्टवेयर में त्रुटियां हो सकती हैं। इसका संबंध सालों पहले 1843 में विश्लेषणात्मक इंजन पर ऐडा बायरन की टिप्पणियों से है जिसमें वे चार्ल्स बैबेज के विश्लेषणात्मक इंजन के लिए प्रोग्राम बनाने में कठिनाई की बात करती हैं।

“

...an analyzing process must equally have been performed in order to furnish the Analytical Engine with the necessary operative data; and that herein may also lie a possible source of error. Granted that the actual mechanism is unerring in its processes, the cards may give it wrong orders.

”

अबोध्य दोषों का वर्णन करने के लिए "बग" शब्द का प्रयोग कई दशकों तक और कंप्यूटर एवं कंप्यूटर सॉफ्टवेयर के आने के पहले इंजीनियरिंग संबंधी शब्दजाल का एक हिस्सा रहा है; संभवतः इसका प्रयोग मूल रूप से हार्डवेयर इंजीनियरिंग में यांत्रिक खराबियों की व्याख्या करने के लिए किया जाता था। उदाहरण के लिए, थॉमस एडीसन ने 1878 में अपने एक सहयोगी के लिए एक पत्र में निम्नांकित शब्दों को लिखा था:

“

It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that 'Bugs' — as such little faults and difficulties are called—show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.

”

^[3]

द्वितीय विश्व युद्ध के दौरान रडार इलेक्ट्रॉनिक्स से जुड़ी समस्याओं को बग (या ग्लिच) कहा जाता था और इस बात के अतिरिक्त सबूत हैं कि इसका इस्तेमाल काफी समय पहले से हो रहा था। 1931 में पहले यांत्रिक पिनबॉल गेम, बैफल बॉल को "बग से मुक्त" कहकर विज्ञापित किया गया था।^[4]

"बग" शब्द की खोज के लिए अक्सर ग्रेस हूपर को जिम्मेदार बताया जाता है जिन्होंने एक प्रारंभिक इलेक्ट्रोमेकानिकल कंप्यूटर में खराबी के कारण का प्रचार किया था।^[5] इस कहानी का एक प्रतीकात्मक संस्करण इस उद्धरण के जरिये यहां दिया जाता है:^[6]

“

In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book. Stemming from the first bug, today we call errors or glitch's [sic] in a program a bug.

”

वास्तव में हूपर वह महिला नहीं थीं जिसने कीट को पाया था, जैसा कि उन्होंने तभी स्वीकार किया था। लॉग बुक में दी गयी तारीख 9 सितम्बर 1947 की थी,^[7]^[8] हालांकि कई बार इसे ग़लती से 1945 बताया गया था।^[9] विलियम "बिल" बुर्के जो बाद में नेवल वीपन्स लेबोरेटरी, डालग्रेन, वर्जीनिया^[10] से जुड़े थे, उनके साथ-साथ जिन ऑपरेटरों ने इसे पाया था, वे इंजीनियरिंग शब्द से परिचित और खुश थे, उन्होंने कीट को "बग के पाए जाने के पहले वास्तविक मामले" के रूप में अंकित करके रख लिया था। हूपर इस कहानी को याद करना पसंद करते थे।^[11] इस लॉग बुक को स्मिथसोनियन नेशनल म्यूजियम ऑफ अमेरिकन हिस्ट्री में पूरी तरह से कीट के साथ संलग्न कर प्रदर्शन के लिए रखा गया है।^[8]

जबकि यह निश्चित है कि हार्वर्ड मार्क द्वितीय के ऑपरेटरों ने "बग" शब्द का आविष्कार नहीं किया था, यह सुझाव दिया जाता है कि उन्होंने इससे संबंधित शब्द डीबग की रचना की थी।" यहां तक कि इसकी संभावना इसलिए भी नहीं है क्योंकि "डीबग" के लिए ऑक्सफोर्ड इंग्लिश डिक्शनरी के अर्थ में 1945 में विमान के इंजन के संदर्भ में डीबगिंग का एक प्रयोग शामिल है। देखें: डीबगिंग.

बचाव[संपादित करें]

बग प्रोग्रामिंग की प्रक्रिया में मानवीय पहलुओं की प्रकृति का एक परिणाम हैं। वे विनिर्देशन, डिजाइन, कोडिंग, डेटा प्रविष्टि और प्रलेखन के दौरान एक सॉफ्टवेयर टीम द्वारा की गई चूक या आपसी गलतफहमी से उत्पन्न होती हैं। उदाहरण के लिए: शब्दों की एक सूची को वर्णमाला क्रम में सजाने के लिए एक अपेक्षाकृत साधारण प्रोग्राम बनाने के क्रम में एक डिजाइन यह समझाने में विफल हो सकता है कि किसी शब्द में हाइफन आने की स्थिति में क्या किया जाना चाहिए। संभवतः काल्पनिक डिजाइन को चुनी गयी प्रोग्रामिंग की भाषा में परिवर्तित करते समय कोई व्यक्ति अनजाने में एक ऑफ-बाइ-वन त्रुटि तैयार कर सकता है और इस तरह सूची में अंतिम शब्द को सजाने में असफल रह सकता है। अंत में, इसके परिणाम स्वरूप बने प्रोग्राम को कंप्यूटर में टाइप करते समय वह गलती से एक '<' कर ले सकता है जहां कि एक '>' होना चाहिए, जिसका नतीजा संभवतः शब्दों को विपरीत वर्णमाला क्रम में सजाने के रूप में सामने आ सकता है। किसी कंप्यूटर प्रोग्राम के विभिन्न भागों के बीच अनायास संपर्क से और अधिक जटिल बग उत्पन्न हो सकते हैं। ऐसा अक्सर होता है क्योंकि कंप्यूटर प्रोग्राम जटिल हो सकते हैं--कुछ मामलों में लाखों की संख्या में लंबी लाइनें हो सकती हैं--जिन्हें अक्सर एक काफी लंबे समय में कई लोगों द्वारा प्रोग्राम किया गया हो सकता है, इसलिए ऐसे प्रोग्रामर मानसिक रूप से हर संभव तरीके का पता लगाने में असमर्थ होते हैं कि कौन के भाग संपर्क कर सकते हैं। रेस कंडीशन नामक एक अन्य श्रेणी का बग या तो उस समय आता है जब कोई प्रक्रिया एक से अधिक थ्रेड में या दो या दो से अधिक प्रक्रियाओं में एक साथ चल रही होती है और जब कोड के महत्वपूर्ण क्रमों के निष्पादन के बिलकुल सही क्रम को सही तरीके से समकालिक नहीं किया गया होता है।

सॉफ्टवेयर उद्योग ने सॉफ्टवेयर लेखन करते हुए अनजाने में बग को शामिल किये जाने से प्रोग्रामरों को बचाने के तरीके खोजने में काफी प्रयास किया है।^[12]^[13] इनमें शामिल हैं:

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

प्रोग्रामिंग तकनीक: बग अक्सर एक सक्रिय प्रोग्राम के आंतरिक डेटा में विसंगतियां पैदा करते हैं। ऐसे प्रोग्राम तैयार किये जा सकते हैं जो सक्रिय होने की स्थिति में अपने स्वयं के आतंरिक डेटा की विसंगतियों की जांच कर सकें. अगर कोई विसंगति पायी जाती है तो प्रोग्राम को तत्काल रोका जा सकता है जिससे कि बग का पता लगाया जा सके और उसे हटाया जा सके. वैकल्पिक रूप से प्रोग्राम सीधे तौर पर विसंगति को दूर करने के प्रयास के लिए और आगे चलते रहने के लिए उपयोगकर्ता को सूचित कर सकता है।

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

प्रोग्रामिंग भाषा का समर्थन: प्रोग्रामिंग भाषाओं में अक्सर ऐसी विशेषताएं शामिल होती हैं जो अपरिवर्ती टाइप सिस्टम्स, सीमित नेम स्पेसेस और मॉड्यूलर प्रोग्रामिंग जैसे बगों के साथ-साथ अन्य बगों को रोकने में प्रोग्रामरों की मदद करती हैं। उदाहरण के लिए, जब कोई प्रोग्रामर इस प्रकार (सूडोकोड) लिखता है - LET REAL_VALUE PI = "THREE AND A BIT", हालांकि यह वाक्य विन्यास के हिसाब से सही हो सकता है लेकिन यह कोड टाइप की जांच करने में विफल रहता है। भाषा और कार्यान्वयन के आधार पर इसे संकलक द्वारा या चलाये जाने के समय पकड़ा जा सकता है। इसके अलावा, हाल ही में खोजी गयी कई भाषाओं में उन विशेषताओं को कोड को इसकी आवश्यकता से धीमा रखने की कीमत पर जान-बूझकर बाहर रखा गया है जो आसानी से बग पैदा करने का कारण बन सकते हैं: सामान्य सिद्धांत यह है कि मूर के नियम के कारण, कंप्यूटर तेज होते जाते हैं और इंजीनियर धीमे होते चले जाते हैं; इसलिए "चालाक", रहस्यमय कोड लिखने की तुलना में सरल, धीमे कोड लिखना लगभग हमेशा बेहतर होता है, विशेष रूप से यह देखते हुए कि रख-रखाव की लागत बहुत अधिक होती है। उदाहरण के लिए, जावा प्रोग्रामिंग की भाषा सूचक अंकगणित का समर्थन नहीं करती है; कुछ भाषाओं जैसे कि पास्कल और स्क्रिप्टिंग की भाषाओं के कार्यान्वयन में, कम से कम डीबगिंग बिल्ड में, अक्सर एरेज (सारणियों) की रनटाइम बाउन्ड्स चेकिंग शामिल होती हैं।

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

इंस्ट्रुमेंटेशन: सक्रिय स्थिति में सॉफ्टवेयर की कार्यक्षमता की निगरानी करने वाले उपकरणों को या तो विशेष रूप से बॉटलनेक जैसी समस्याओं का पता लगाने के लिए या सही तरीके से कार्य करने का आश्वासन देने के लिए स्पष्ट रूप से कोड में सन्निहित किया जा सकता है (संभवतः PRINT "I AM HERE" जैसे एक सरल बयान के रूप में) या उपकरणों के रूप में प्रदान किया जा सकता है। यह पता लगाना अक्सर आश्चर्यजनक होता है कि किसी एक कोड द्वारा ज्यादातर समय कहां पर लिया जाता है और इन अनुमानों को हटाने के लिए कोड को दुबारा लिखने की आवश्यकता हो सकती है।

डीबगिंग[संपादित करें]

बग का पता लगाना और उसे हटाना या "डीबगिंग" अक्सर कंप्यूटर प्रोग्रामिंग का एक महत्वपूर्ण भाग होता है। एक प्रारंभिक कंप्यूटर विशेषज्ञ, मौरिस विल्केस ने 1940 के दशक में अपनी एक अनुभूति में उल्लेख किया था कि उनकी जिन्दगी का अधिकांश शेष भाग अपने स्वयं के प्रोग्रामों की गलतियों का पता लगाने में बीत जाएगा.^[14] जैसे-जैसे कंप्यूटर प्रोग्राम और अधिक जटिल होते जाते हैं, बग और अधिक सामान्य एवं मुश्किल से दूर किये जाने वाले हो जाते हैं। अक्सर प्रोग्रामर नए कोड लिखने की तुलना में बगों का पता लगाने और उन्हें दूर करने में ज्यादा समय लगाते हैं और कहीं अधिक प्रयास करते हैं। सॉफ्टवेयर परीक्षक ऐसे पेशेवर व्यक्ति होते हैं जिनका प्रमुख कार्य बगों का पता लगाना या परीक्षण में सहयोग करने वाले कोड लिखना होता है। कुछ प्रोजेक्टों में प्रोग्राम विकसित करने की तुलना में ज्यादा संसाधन परीक्षण में खर्च किये जा सकते हैं।

आम तौर पर डिबगिंग का सबसे अधिक मुश्किल भाग स्रोत कोड में बग का पता लगाना है। एक बार जब इसका पता लग जाता है तो इसे ठीक करना आम तौर पर अपेक्षाकृत आसान होता है। डीबगर के रूप में जाने जाने वाले प्रोग्राम भी मौजूद हैं जो एक-एक लाइन कर कोड को कार्यान्वित करने, परिवर्ती मानों पर नजर रखने और प्रोग्राम के आचरण को समझने वाली अन्य सुविधाओं के जरिये बग का पता लगाने में प्रोग्रामरों की मदद करते हैं। एक डिबगर के बिना प्रोग्राम के कार्यान्वयन का पता लगाने या मानों को दिखाने के लिए कोड को इस तरह जोड़ा जा सकता है कि संदेशों या मानों को एक कंसोल में (उदाहरण के लिए सी (C) प्रोग्रामिंग की भाषा में printf) के साथ) या एक विंडो में या लॉग फ़ाइल में लिखा जा सके।

हालांकि, एक डीबगर की सहायता से भी बग का पता लगाना कुछ हद तक एक कला है। किसी प्रोग्राम के एक सेक्शन में मौजूद किसी बग के लिए एक पूरी तरह से दूसरे सेक्शन में विफलता का कारण बनना असामान्य नहीं है जिसके कारण सिस्टम के एक स्पष्टतः असंबद्ध भाग में इसका पता लगाना (उदाहरण के लिए, एक ग्राफिक्स रेंडरिंग की दिनचर्या में किसी त्रुटि के कारण एक फ़ाइल आई/ओ संबंधी दिनचर्या का असफल हो जाना) विशेष रूप से मुश्किल हो जाता है।

कभी-कभी बग एक अलग दोष नहीं होता है बल्कि यह प्रोग्रामर की ओर से सोच या योजना की एक त्रुटि का प्रतिनिधित्व करता है। इस तरह की तार्किक त्रुटियों के लिए प्रोग्राम के उस भाग की संपूर्ण मरम्मत या उसके दुबारा लेखन की आवश्यकता होती है। कोड समीक्षा के हिस्से के रूप में, अगर ऐसा दिखाया जा सके कि इसके कार्यान्वयन में कुछ त्रुटिपूर्ण तर्क मौजूद हैं, एक विशेष प्रकार के कोड का इस्तेमाल करके ऐसे किसी बग को दुबारा उत्पन्न किये बिना ही अक्सर इन त्रुटियों का पता लगाया जा सकता है।

लेकिन कहीं अधिक विशेष रूप से किसी बग का पता लगाने में पहला चरण है इसे विश्वसनीय तरीके से पुनः प्रस्तुत करना। एक बार जब बग को पुनः प्रस्तुत कर दिया जाता है, प्रोग्रामर दोषपूर्ण क्षेत्र में प्रोग्राम के क्रियान्वयन की निगरानी करने के लिए एक डीबगर का या किसी अन्य उपकरण का इस्तेमाल कर सकता है और उस स्थान का पता लगा सकता है जिसमें प्रोग्राम अपने उद्देश्य से भटक गया है।

बग को पुनः प्रस्तुत करना अक्सर आसान नहीं होता है। कुछ बग प्रोग्राम की निविष्टियों द्वारा उत्पन्न होते हैं जिन्हें पुनः उत्पन्न करना प्रोग्रामर के लिए मुश्किल हो सकता है। थिरैक-25 विकिरण मशीन से हुई मौतों का एक कारण एक बग था (विशेष रूप से एक रेस कंडीशन) जो केवल उस समय उत्पन्न हुआ था जब मशीन संचालक ने एक उपचार योजना की प्रविष्टि बहुत अधिक तेजी से कर दी; इस कार्य के लिए सक्षम होने में कई दिनों का अभ्यास करना पड़ा था, इसलिए बग परीक्षण के दौरान या उस समय उत्पन्न नहीं हुआ था जब निर्माता ने इसकी नक़ल करने की कोशिश की थी। अन्य बग प्रोग्राम को एक डीबगर के जरिये चलाये जाने से गायब हो सकते हैं; ये हाइजेनबग्स होते हैं (हाइजेनबर्ग के अनिश्चितता के सिद्धांत पर मजाकिया तौर पर यह नाम दिया गया था).

डिबगिंग अभी भी एक उबाऊ कार्य है जिसके लिए काफी प्रयास की आवश्यकता होती है। 1990 के दशक से, विशेष रूप से एरियन 5 फ्लाइट 501 की दुर्घटना के बाद से डीबगिंग में प्रभावी स्वचालित सहयोग विकसित करने में नए सिरे से दिलचस्पी बढ़ी है। उदाहरण के लिए, काल्पनिक व्याख्या के जरिये परिवर्ती कोड विश्लेषण के तरीकों ने पहले से ही महत्वपूर्ण उपलब्धियां दी हैं, हालांकि अभी भी काफी हद तक बाकी बचा हुआ कार्य प्रगति में है।

जैसा कि किसी भी रचनात्मक कार्य के साथ होता है, कभी-कभी प्रेरणा की एक चमक भी एक समाधान दिखा देती है, लेकिन यह दुर्लभ है और परिभाषा के अनुसार, इस पर भरोसा नहीं किया जा सकता है।

बग के लिए कक्षाएं भी आयोजित की जाती हैं जिनका स्वयं कोड से कोई मतलब नहीं होता है। उदाहरण के लिए, अगर कोई एक दोषपूर्ण प्रलेखन या हार्डवेयर पर निर्भर है, कोड पूरी तरह से सही तरीके से उसी रूप में लिखा जा सकता है जैसा कि प्रलेखन कहता है लेकिन लेकिन बग वास्तव में प्रलेखन या हार्डवेयर में रहता है, कोड में नहीं। हालांकि, सिस्टम के अन्य भागों की बजाय कोड को बदलना आम है, क्योंकि इसे बदलने में समय और लागत आम तौर पर कम लगता है। सन्निहित प्रणालियों (एम्बेडेड सिस्टम्स) में हार्डवेयर बग के लिए अक्सर वर्कअराउंड होते हैं, क्योंकि हार्डवेयर का पुनर्निर्माण करने की तुलना में रोम (ROM) का एक नया संस्करण तैयार करना कहीं अधिक सस्ता होता है, विशेष रूप से अगर ये कमोडिटी आइटम होते हैं।

बग प्रबंधन[संपादित करें]

ऐसे ज्ञात बगों के साथ सॉफ्टवेयर का जारी किया जाना एक आम बात है जो गैर-महत्वपूर्ण माने जाते हैं अर्थात जो उत्पाद के साथ ज्यादातर उपयोगकर्ताओं के मुख्य अनुभव को प्रभावित नहीं करते हैं। चूंकि परिभाषा के अनुसार सॉफ्टवेयर उत्पादों में किसी भी संख्या में अज्ञात बग मौजूद हो सकते हैं, परीक्षण के दौरान मापन से बचे हुए संभावित बगों की संख्या का एक अनुमान प्राप्त किया जा सकता है; उत्पाद को जितनी देर तक परीक्षण या विकसित किया जाता है वह और अधिक विश्वसनीय हो जाता है ("अगर हमारे पास पिछले सप्ताह 200 बग थे तो इस सप्ताह हमारे पास 100 बग होने चाहिएं). ज्यादातर बड़ी सॉफ्टवेयर परियोजनाओं के पास "ज्ञात बग" की दो सूचियां होती हैं - एक वह जिसके बारे में सॉफ्टवेयर टीम को जानकारी होती है और दूसरी जिसके बारे में उपयोगकर्ताओं को बताया जाता है। यह तथ्यों का छिपाया जाना नहीं है बल्कि उपयोगकर्ता उत्पाद के आंतरिक कार्यप्रणाली पर ध्यान नहीं देते हैं। दूसरी सूची उपयोगकर्ताओं को उन बगों के बारे में जानकारी देती है जिन्हें मौजूदा रिलीज में या बिलकुल भी दूर नहीं किया गया है और एक वर्कअराउंड की पेशकश भी की जा सकती है।

बगों को दूर नहीं किये जाने के कई कारण होते हैं:

विकासकों (डेवलपर्स) के पास अक्सर इसके लिए समय नहीं होता है या सभी कम-गंभीर बगों को ठीक करना किफायती नहीं होता है।
बग को ऐसे नए संस्करण या पैच में ठीक किया गया हो सकता है जिसे अभी तक रिलीज नहीं किया गया है।
बग को ठीक करने के लिए कोड में किये जाने वाले आवश्यक बदलाव बड़े, महंगे या प्रोजेक्ट की समाप्ति में विलंब पैदा करने वाले हो सकते हैं।
यहां तक कि सरल दिखाई देने होने वाले सुधार भी सिस्टम में नए अज्ञात बगों के शामिल होने के मौके प्रदान कर सकते हैं। एक परीक्षण/सुधार चक्र के अंत में कुछ प्रबंधक के कुछ सबसे अधिक महत्वपूर्ण बगों को ठीक करने की अनुमति दे सकते हैं।
उपयोगकर्ता संभवतः अप्रलेखित, बग जैसे आचरण पर भरोसा कर सकते हैं, खास तौर पर अगर स्क्रिप्ट या मैक्रोज़ एक आचरण पर निर्भर करते हैं; ये एक जबरदस्त बदलाव ला सकते हैं।
यह "एक बग नहीं है". अपेक्षित और प्रदत्त व्यवहार के बीच एक गलतफहमी पैदा हो गई है।

उपरोक्त को देखते हुए किसी वास्तविक जटिलता वाले एक पूरी तरह से बग-मुक्त सॉफ्टवेयर का लेखन अक्सर असंभव माना जाता है। इस प्रकार बगों को इनकी गंभीरता के आधार पर वर्गीकृत किया जाता है और कम-तीव्रता वाले गैर-गंभीर बगों को बर्दाश्त कर लिया जाता है क्योंकि वे अधिकांश उपयोगकर्ताओं के लिए सिस्टम के समुचित संचालन को प्रभावित नहीं करते हैं। नासा के एसएटीसी ने त्रुटियों की संख्या प्रति 1000 लाइनों के कोड (एसएलओसी)^{[उद्धरण चाहिए]} में 0.1 से भी कम करने में कामयाबी हासिल की थी लेकिन इसे किसी वास्तविक दुनिया के प्रोजेक्ट के लिए संभव नहीं समझा गया।

किसी बग की गंभीरता इसके ठीक करने के महत्त्व के बराबर नहीं होती है और दोनों का मापन और प्रबंधन अलग-अलग किया जाना चाहिए। एक माइक्रोसॉफ्ट विंडोज सिस्टम पर मौत का नीला स्क्रीन अपेक्षाकृत एक गंभीर होता है लेकिन अगर यह केवल चरम परिस्थितियों में होता है, खास तौर पर अगर ये अच्छी तरह उपचारित और परिहार्य होते हैं, किसी आइकन द्वारा अपने कार्य का सही प्रतिधिनित्व नहीं किये जाने की तुलना में इसमें सुधार किया जाना कम महत्वपूर्ण हो सकता है जो हालांकि पूरी तरह सौंदर्य से संबंधित है लेकिन यह हर दिन हजारों उपयोगकर्ताओं को भ्रमित कर सकता है। यह संतुलन ज़ाहिर तौर पर कई कारकों पर निर्भर करता है; विशेषज्ञ उपयोगकर्ताओं को नौसिखियों से अलग उम्मीदें रहती हैं, एक ऊँचे दर्जे का बाजार एक सामान्य उपभोक्ता बाजार और इसी तरह के अन्य बाजारों से अलग होता है। एक बेहतर संतुलन प्राप्त करने के लिए कुछ सॉफ्टवेयर डेवलपर एक औपचारिक बग ट्राइएज प्रक्रिया (चिकित्सा शब्दावली को लेकर) का उपयोग करते हैं जिसमें प्रत्येक नए बग को इसकी गंभीरता, आवृत्ति, जोखिम और अन्य पूर्व-निर्धारित कारकों के आधार पर एक प्राथमिकता दी जाती है।^{[उद्धरण चाहिए]}

एरिक एस. रेमंड द्वारा लाइनस लॉ के रूप में प्रचारित एक विचारधारा कहती है कि अन्य सॉफ्टवेयर की तुलना में लोकप्रिय ओपन-सोर्स सॉफ्टवेयर में कम या कोई बग नहीं होने के मौके ज्यादा होते हैं क्योंकि "अधिक ध्यान देने पर, सभी बग हल्के होते हैं".^[15] इस दावे को विवादित करार दिया गया है, हालांकि: कंप्यूटर सुरक्षा विशेषज्ञ एलियास लेवी ने लिखा है कि "जटिल, कम स्पष्ट और अप्रलेखित स्रोत कोड में कमजोरियों को छिपाना कहीं आसान होता है" क्योंकि "यहां तक कि अगर लोग कोड की समीक्षा करते है तो इसका मतलब यह नहीं होता है कि वे ऐसा करने के लिए योग्य होते हैं।"^[16]

इंजीनियरिंग प्रबंधन के किसी अन्य भाग की तरह बग प्रबंधन सावधानी पूर्वक और समझदारी से किया जाना चाहिए क्योंकि "जिसका मापन होता है उसे ही ठीक किया जाता है"^[17] और शुद्ध रूप से बगों की गिनती द्वारा प्रबंधन अनपेक्षित परिणाम दे सकता है। उदाहरण के लिए, अगर डेवलपरों को उनके द्वारा ठीक किये गए बगों की संख्या के आधार पर पुरस्कृत किया जाता है तो वे स्वाभाविक रूप से -- सबसे कठिन और संभवतः सबसे जोखिमपूर्ण और सबसे महत्वपूर्ण बग को अंतिम संभव पलों के लिए छोड़कर सबसे आसान बग को पहले ठीक करेंगे ("मेरे पास अपनी सूची में एक मात्र बग है लेकिन यह "सूरज को पश्चिम से उगाने" की बात करता है). अगर प्रबंधन की प्रवृत्ति ठीक किये गए बगों के आधार पर पुरस्कृत करने की है तो कुछ डेवलेपर यह जानते हुए भी कि वे इन बगों को बाद में ठीक कर सकते हैं और इसके लिए पुरस्कृत किये जा सकते हैं, शीघ्रता से लापरवाह कोड लिख सकते हैं जबकि सावधान, संभवतः "धीमे" डेवलपरों को उन बगों के लिए कभी पुरस्कृत नहीं किया जाता है जो वहां कभी मौजूद ही नहीं थे।

सुरक्षा संबंधी कमजोरियां[संपादित करें]

दुर्भावनापूर्ण सॉफ्टवेयर किसी सिस्टम में ज्ञात कमजोरियों का फायदा उठाने की कोशिश कर सकते हैं - जो बग हो सकते हैं और नहीं भी हो सकते हैं। वायरस अपने आप में बग नहीं होते हैं - वे आम तौर पर प्रोग्राम होते हैं जो साफ़ तौर पर वही करते हैं जिनके लिए उन्हें डिजाइन किया गया होता है। हालांकि वायरसों को लोकप्रिय प्रेस में कभी-कभी इसी रूप में संदर्भित किया जाता है।^{[उद्धरण चाहिए]}

सामान्य प्रकार के कंप्यूटर बग[संपादित करें]

वैचारिक त्रुटि (कोड वाक्य विन्यास के हिसाब से सही है लेकिन प्रोग्रामर या डिजाइनर का इरादा इसके जरिये कुछ और करने का था)

अंकगणितीय बग[संपादित करें]

शून्य से विभाज्यता
अंकगणितीय अतिप्रवाह या अधोप्रवाह
राउंडिंग या संख्यानुसार अस्थिर एल्गोरिदम के कारण अंकगणितीय परिशुद्धता में कमी

तार्किक बग (लॉजिक बग)[संपादित करें]

अनंत लूप और अनंत रिकर्शन
ऑफ बाइ वन एरर, लूपिंग के समय बहुत अधिक या बहुत कम एक की गिनती

वाक्य विन्यास संबंधी बग[संपादित करें]

गलत ऑपरेटर का प्रयोग, जैसे कि समानता परीक्षण की बजाय एसाइनमेंट को पूरा करना। साधारण मामलों में अक्सर संकलक द्वारा इसकी चेतावनी दी जाती है; कई भाषाओं में भाषा वाक्य विन्यास द्वारा जान-बूझकर इसके विरुद्ध संरक्षित किया जाता है।

संसाधन संबंधी बग (रिसोर्स बग)[संपादित करें]

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

मल्टी-थ्रेडिंग प्रोग्रामिंग बग[संपादित करें]

गतिरोध (डेडलॉक)
रेस कंडीशन
महत्वपूर्ण भागों, म्युचुअल अपवर्जनों और समवर्ती प्रक्रमण की अन्य सुविधाओं में समरूपता की त्रुटियां. टाइम-ऑफ-चेक-टू-टाइम-ऑफ-यूज (टीओसीटीओयू) असुरक्षित महत्वपूर्ण अनुभाग का एक रूप है।

टीमवर्किंग बग[संपादित करें]

अप्रसारित अपडेट; जैसे कि प्रोग्रामर "माईएड (myAdd)" को बदल देता है लेकिन "माईसब्स्ट्रेक्ट (mySubstract)" को बदलना भूल जाता है जो एक ही एल्गोरिदम का उपयोग करता है। इन त्रुटियों को खुद को ना दोहराएं के दर्शन से कम किया जा सकता है।
अप्रचलित या गलत टिप्पणियां: कई प्रोग्रामर यह मानते हैं कि टिप्पणियां बिलकुल सही तरीके से कोड का वर्णन करती हैं।
प्रलेखन और वास्तविक उत्पाद के बीच भिन्नताएं

इन्हें भी देखें[संपादित करें]