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

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

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

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

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

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

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

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

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

बचाव
डीबगिंग
शब्द-व्युत्पत्ति
बग प्रबंधन