सॉफ्टवेयर बग
सॉफ्टवेयर बग, किसी कंप्यूटर प्रोग्राम या प्रणाली की ऐसी त्रुटि, दोष, गलती, विफलता या खोट (फॉल्ट) को वर्णित करने के लिए इस्तेमाल किया जाने वाला एक आम शब्द है जो गलत और अप्रत्याशित परिणाम देती हैं या इसके अनपेक्षित तरीके से व्यवहार करने का कारण बनती हैं। ज्यादातर बग लोगों द्वारा किसी प्रोग्राम के स्रोत कोड या इसकी डिजाइन में की गयी गलतियों और त्रुटियों की वजह से उत्पन्न होते हैं और कुछ गलत कोड बनाने वाले कम्पाइलरों के कारण पैदा होते हैं। एक ऐसा प्रोग्राम जिसमें बड़ी संख्या में बग पाए जाते हैं और/या जो बग इसकी कार्यक्षमता पर बुरी तरह हस्तक्षेप करते हैं, उन्हें "बग्गी" कहा जाता है। किसी प्रोग्राम में बग का ब्यौरा देने वाली रिपोर्ट को आम तौर पर बग रिपोर्ट, फॉल्ट रिपोर्ट, प्रॉब्लम रिपोर्ट, ट्रबल रिपोर्ट, चेंज रिक्वेस्ट और इसी तरह के नामों से जाना जाता है।
बग, टाइप I और टाइप II त्रुटियों को सक्रिय कर देते हैं जो बदले में व्यापक प्रकार के तरंगित प्रभाव पैदा कर सकते हैं जिसके कारण प्रोग्राम के उपयोगकर्ता को विविध स्तरों की असुविधाओं का सामना करना पड़ सकता है। कुछ बग प्रोग्राम की कार्यक्षमता पर सिर्फ एक हल्का सा प्रभाव डालते हैं और इस तरह एक लंबे समय तक उनका पता ही नहीं चल पाता है। अधिक गंभीर बग प्रोग्राम को क्रैश (नष्ट) या फ्रीज (निष्क्रिय) कर सकते हैं जिसकी वजह से इसकी सेवा बंद हो सकती है। अन्य बग सुरक्षा बग के रूप में समझे जाते हैं, उदाहरण के लिए, ये अनधिकृत विशेषाधिकार प्राप्त करने के क्रम में एक दुर्भावनापूर्ण उपयोगकर्ता को पहुंच संबंधी नियंत्रण का उपयोग करने में सक्षम बना सकते हैं।
बग के परिणाम अत्यंत गंभीर हो सकते हैं। 1980 के दशक में थिरेक-25 विकिरण चिकित्सा मशीन को नियंत्रित करने वाले कोड में मौजूद बग कई मरीजों की मौत के लिए सीधे तौर पर जिम्मेदार थे। 1996 में यूरोपीय अंतरिक्ष एजेंसी का 1 बिलियन अमेरिकी डॉलर का प्रोटोटाइप एरियन-5 रॉकेट ऑन-बोर्ड गाइडेंस कंप्यूटर प्रोग्राम में बग की मौजूदगी के कारण लॉन्च होने के एक मिनट से भी कम समय में नष्ट हो गया था। जून 1994 में एक रॉयल एयर फोर्स चिनूक, मल ऑफ किनटायर में दुर्घटनाग्रस्त हो गया था जिसमें 29 लोग मारे गए थे। शुरुआत में इसे एक पायलट की गलती कहकर खारिज कर दिया गया था लेकिन "कंप्यूटर वीकली" द्वारा की गयी एक जांच ने पर्याप्त सबूतों का खुलासा किया जो हाउस ऑफ लॉर्ड्स की एक जांच को यह विश्वास दिलाने में कामयाब रहा कि ऐसा विमान के इंजन को नियंत्रित करने वाले कंप्यूटर में मौजूद एक सॉफ्टवेयर बग के कारण हुआ हो सकता है।
2002 में अमेरिकी वाणिज्य विभाग के नेशनल इंस्टिट्यूट ऑफ स्टैंडर्ड्स एंड टेक्नोलॉजी द्वारा कराये गए एक अध्ययन ने यह निष्कर्ष दिया कि "सॉफ्टवेयर बग या एरर इतने व्यापक और हानिकारक हैं कि ये अमेरिकी अर्थव्यवस्था को एक अनुमान के मुताबिक़ सालाना 59 बिलियन डॉलर या सकल घरेलू उत्पाद के लगभग 0.6 प्रतिशत का नुकसान पहुंचाते हैं।"
यह अवधारणा कि सॉफ्टवेयर में त्रुटियां हो सकती हैं। इसका संबंध सालों पहले 1843 में विश्लेषणात्मक इंजन पर ऐडा बायरन की टिप्पणियों से है जिसमें वे चार्ल्स बैबेज के विश्लेषणात्मक इंजन के लिए प्रोग्राम बनाने में कठिनाई की बात करती हैं।
अबोध्य दोषों का वर्णन करने के लिए "बग" शब्द का प्रयोग कई दशकों तक और कंप्यूटर एवं कंप्यूटर सॉफ्टवेयर के आने के पहले इंजीनियरिंग संबंधी शब्दजाल का एक हिस्सा रहा है; संभवतः इसका प्रयोग मूल रूप से हार्डवेयर इंजीनियरिंग में यांत्रिक खराबियों की व्याख्या करने के लिए किया जाता था। उदाहरण के लिए, थॉमस एडीसन ने 1878 में अपने एक सहयोगी के लिए एक पत्र में निम्नांकित शब्दों को लिखा था:
द्वितीय विश्व युद्ध के दौरान रडार इलेक्ट्रॉनिक्स से जुड़ी समस्याओं को "बग" (या ग्लिच) कहा जाता था और इस बात के अतिरिक्त सबूत हैं कि इसका इस्तेमाल काफी समय पहले से हो रहा था। 1931 में पहले यांत्रिक पिनबॉल गेम, बैफल बॉल को "बग से मुक्त" कहकर विज्ञापित किया गया था।
"बग" शब्द की खोज के लिए अक्सर ग्रेस हूपर को जिम्मेदार बताया जाता है जिन्होंने एक प्रारंभिक इलेक्ट्रोमेकानिकल कंप्यूटर में खराबी के कारण का प्रचार किया था। इस कहानी का एक प्रतीकात्मक संस्करण इस उद्धरण के जरिये यहां दिया जाता है:
वास्तव में हूपर वह महिला नहीं थीं जिसने कीट को पाया था, जैसा कि उन्होंने तभी स्वीकार किया था। लॉग बुक में दी गयी तारीख 9 सितम्बर 1947 की थी, हालांकि कई बार इसे ग़लती से 1945 बताया गया था। विलियम "बिल" बुर्के जो बाद में नेवल वीपन्स लेबोरेटरी, डालग्रेन, वर्जीनिया से जुड़े थे, उनके साथ-साथ जिन ऑपरेटरों ने इसे पाया था, वे इंजीनियरिंग शब्द से परिचित और खुश थे, उन्होंने कीट को "बग के पाए जाने के पहले वास्तविक मामले" के रूप में अंकित करके रख लिया था। हूपर इस कहानी को याद करना पसंद करते थे। इस लॉग बुक को स्मिथसोनियन नेशनल म्यूजियम ऑफ अमेरिकन हिस्ट्री में पूरी तरह से कीट के साथ संलग्न कर प्रदर्शन के लिए रखा गया है।
जबकि यह निश्चित है कि हार्वर्ड मार्क द्वितीय के ऑपरेटरों ने "बग" शब्द का आविष्कार नहीं किया था, यह सुझाव दिया जाता है कि उन्होंने इससे संबंधित शब्द डीबग की रचना की थी।" यहां तक कि इसकी संभावना इसलिए भी नहीं है क्योंकि "डीबग" के लिए ऑक्सफोर्ड इंग्लिश डिक्शनरी के अर्थ में 1945 में विमान के इंजन के संदर्भ में डीबगिंग का एक प्रयोग शामिल है। "देखें:" डीबगिंग.
बग प्रोग्रामिंग की प्रक्रिया में मानवीय पहलुओं की प्रकृति का एक परिणाम हैं। वे विनिर्देशन, डिजाइन, कोडिंग, डेटा प्रविष्टि और प्रलेखन के दौरान एक सॉफ्टवेयर टीम द्वारा की गई चूक या आपसी गलतफहमी से उत्पन्न होती हैं। उदाहरण के लिए: शब्दों की एक सूची को वर्णमाला क्रम में सजाने के लिए एक अपेक्षाकृत साधारण प्रोग्राम बनाने के क्रम में एक डिजाइन यह समझाने में विफल हो सकता है कि किसी शब्द में हाइफन आने की स्थिति में क्या किया जाना चाहिए। संभवतः काल्पनिक डिजाइन को चुनी गयी प्रोग्रामिंग की भाषा में परिवर्तित करते समय कोई व्यक्ति अनजाने में एक ऑफ-बाइ-वन त्रुटि तैयार कर सकता है और इस तरह सूची में अंतिम शब्द को सजाने में असफल रह सकता है। अंत में, इसके परिणाम स्वरूप बने प्रोग्राम को कंप्यूटर में टाइप करते समय वह गलती से एक '' होना चाहिए, जिसका नतीजा संभवतः शब्दों को विपरीत वर्णमाला क्रम में सजाने के रूप में सामने आ सकता है। किसी कंप्यूटर प्रोग्राम के विभिन्न भागों के बीच अनायास संपर्क से और अधिक जटिल बग उत्पन्न हो सकते हैं। ऐसा अक्सर होता है क्योंकि कंप्यूटर प्रोग्राम जटिल हो सकते हैं--कुछ मामलों में लाखों की संख्या में लंबी लाइनें हो सकती हैं--जिन्हें अक्सर एक काफी लंबे समय में कई लोगों द्वारा प्रोग्राम किया गया हो सकता है, इसलिए ऐसे प्रोग्रामर मानसिक रूप से हर संभव तरीके का पता लगाने में असमर्थ होते हैं कि कौन के भाग संपर्क कर सकते हैं। "रेस कंडीशन" नामक एक अन्य श्रेणी का बग या तो उस समय आता है जब कोई प्रक्रिया एक से अधिक थ्रेड में या दो या दो से अधिक प्रक्रियाओं में एक साथ चल रही होती है और जब कोड के महत्वपूर्ण क्रमों के निष्पादन के बिलकुल सही क्रम को सही तरीके से समकालिक नहीं किया गया होता है।
सॉफ्टवेयर उद्योग ने सॉफ्टवेयर लेखन करते हुए अनजाने में बग को शामिल किये जाने से प्रोग्रामरों को बचाने के तरीके खोजने में काफी प्रयास किया है। इनमें शामिल हैं:
बग का पता लगाना और उसे हटाना या "डीबगिंग" अक्सर कंप्यूटर प्रोग्रामिंग का एक महत्वपूर्ण भाग होता है। एक प्रारंभिक कंप्यूटर विशेषज्ञ, मौरिस विल्केस ने 1940 के दशक में अपनी एक अनुभूति में उल्लेख किया था कि उनकी जिन्दगी का अधिकांश शेष भाग अपने स्वयं के प्रोग्रामों की गलतियों का पता लगाने में बीत जाएगा. जैसे-जैसे कंप्यूटर प्रोग्राम और अधिक जटिल होते जाते हैं, बग और अधिक सामान्य एवं मुश्किल से दूर किये जाने वाले हो जाते हैं। अक्सर प्रोग्रामर नए कोड लिखने की तुलना में बगों का पता लगाने और उन्हें दूर करने में ज्यादा समय लगाते हैं और कहीं अधिक प्रयास करते हैं। सॉफ्टवेयर परीक्षक ऐसे पेशेवर व्यक्ति होते हैं जिनका प्रमुख कार्य बगों का पता लगाना या परीक्षण में सहयोग करने वाले कोड लिखना होता है। कुछ प्रोजेक्टों में प्रोग्राम विकसित करने की तुलना में ज्यादा संसाधन परीक्षण में खर्च किये जा सकते हैं।
आम तौर पर डिबगिंग का सबसे अधिक मुश्किल भाग स्रोत कोड में बग का पता लगाना है। एक बार जब इसका पता लग जाता है तो इसे ठीक करना आम तौर पर अपेक्षाकृत आसान होता है। डीबगर के रूप में जाने जाने वाले प्रोग्राम भी मौजूद हैं जो एक-एक लाइन कर कोड को कार्यान्वित करने, परिवर्ती मानों पर नजर रखने और प्रोग्राम के आचरण को समझने वाली अन्य सुविधाओं के जरिये बग का पता लगाने में प्रोग्रामरों की मदद करते हैं। एक डिबगर के बिना प्रोग्राम के कार्यान्वयन का पता लगाने या मानों को दिखाने के लिए कोड को इस तरह जोड़ा जा सकता है कि संदेशों या मानों को एक कंसोल में (उदाहरण के लिए सी (C) प्रोग्रामिंग की भाषा में "printf)" के साथ) या एक विंडो में या लॉग फ़ाइल में लिखा जा सके।
हालांकि, एक डीबगर की सहायता से भी बग का पता लगाना कुछ हद तक एक कला है। किसी प्रोग्राम के एक सेक्शन में मौजूद किसी बग के लिए एक पूरी तरह से दूसरे सेक्शन में विफलता का कारण बनना असामान्य नहीं है जिसके कारण सिस्टम के एक स्पष्टतः असंबद्ध भाग में इसका पता लगाना (उदाहरण के लिए, एक ग्राफिक्स रेंडरिंग की दिनचर्या में किसी त्रुटि के कारण एक फ़ाइल आई/ओ संबंधी दिनचर्या का असफल हो जाना) विशेष रूप से मुश्किल हो जाता है।
कभी-कभी बग एक अलग दोष नहीं होता है बल्कि यह प्रोग्रामर की ओर से सोच या योजना की एक त्रुटि का प्रतिनिधित्व करता है। इस तरह की "तार्किक त्रुटियों" के लिए प्रोग्राम के उस भाग की संपूर्ण मरम्मत या उसके दुबारा लेखन की आवश्यकता होती है। कोड समीक्षा के हिस्से के रूप में, अगर ऐसा दिखाया जा सके कि इसके कार्यान्वयन में कुछ त्रुटिपूर्ण तर्क मौजूद हैं, एक विशेष प्रकार के कोड का इस्तेमाल करके ऐसे किसी बग को दुबारा उत्पन्न किये बिना ही अक्सर इन त्रुटियों का पता लगाया जा सकता है।
लेकिन कहीं अधिक विशेष रूप से किसी बग का पता लगाने में पहला चरण है इसे विश्वसनीय तरीके से पुनः प्रस्तुत करना। एक बार जब बग को पुनः प्रस्तुत कर दिया जाता है, प्रोग्रामर दोषपूर्ण क्षेत्र में प्रोग्राम के क्रियान्वयन की निगरानी करने के लिए एक डीबगर का या किसी अन्य उपकरण का इस्तेमाल कर सकता है और उस स्थान का पता लगा सकता है जिसमें प्रोग्राम अपने उद्देश्य से भटक गया है।
बग को पुनः प्रस्तुत करना अक्सर आसान नहीं होता है। कुछ बग प्रोग्राम की निविष्टियों द्वारा उत्पन्न होते हैं जिन्हें पुनः उत्पन्न करना प्रोग्रामर के लिए मुश्किल हो सकता है। थिरैक-25 विकिरण मशीन से हुई मौतों का एक कारण एक बग था (विशेष रूप से एक रेस कंडीशन) जो केवल उस समय उत्पन्न हुआ था जब मशीन संचालक ने एक उपचार योजना की प्रविष्टि बहुत अधिक तेजी से कर दी; इस कार्य के लिए सक्षम होने में कई दिनों का अभ्यास करना पड़ा था, इसलिए बग परीक्षण के दौरान या उस समय उत्पन्न नहीं हुआ था जब निर्माता ने इसकी नक़ल करने की कोशिश की थी। अन्य बग प्रोग्राम को एक डीबगर के जरिये चलाये जाने से गायब हो सकते हैं; ये हाइजेनबग्स होते हैं (हाइजेनबर्ग के अनिश्चितता के सिद्धांत पर मजाकिया तौर पर यह नाम दिया गया था).
डिबगिंग अभी भी एक उबाऊ कार्य है जिसके लिए काफी प्रयास की आवश्यकता होती है। 1990 के दशक से, विशेष रूप से एरियन 5 फ्लाइट 501 की दुर्घटना के बाद से डीबगिंग में प्रभावी स्वचालित सहयोग विकसित करने में नए सिरे से दिलचस्पी बढ़ी है। उदाहरण के लिए, काल्पनिक व्याख्या के जरिये परिवर्ती कोड विश्लेषण के तरीकों ने पहले से ही महत्वपूर्ण उपलब्धियां दी हैं, हालांकि अभी भी काफी हद तक बाकी बचा हुआ कार्य प्रगति में है।
जैसा कि किसी भी रचनात्मक कार्य के साथ होता है, कभी-कभी प्रेरणा की एक चमक भी एक समाधान दिखा देती है, लेकिन यह दुर्लभ है और परिभाषा के अनुसार, इस पर भरोसा नहीं किया जा सकता है।
बग के लिए कक्षाएं भी आयोजित की जाती हैं जिनका स्वयं कोड से कोई मतलब नहीं होता है। उदाहरण के लिए, अगर कोई एक दोषपूर्ण प्रलेखन या हार्डवेयर पर निर्भर है, कोड पूरी तरह से सही तरीके से उसी रूप में लिखा जा सकता है जैसा कि प्रलेखन कहता है लेकिन लेकिन बग वास्तव में प्रलेखन या हार्डवेयर में रहता है, कोड में नहीं। हालांकि, सिस्टम के अन्य भागों की बजाय कोड को बदलना आम है, क्योंकि इसे बदलने में समय और लागत आम तौर पर कम लगता है। सन्निहित प्रणालियों (एम्बेडेड सिस्टम्स) में हार्डवेयर बग के लिए अक्सर वर्कअराउंड होते हैं, क्योंकि हार्डवेयर का पुनर्निर्माण करने की तुलना में रोम (ROM) का एक नया संस्करण तैयार करना कहीं अधिक सस्ता होता है, विशेष रूप से अगर ये कमोडिटी आइटम होते हैं।
ऐसे ज्ञात बगों के साथ सॉफ्टवेयर का जारी किया जाना एक आम बात है जो गैर-महत्वपूर्ण माने जाते हैं अर्थात जो उत्पाद के साथ ज्यादातर उपयोगकर्ताओं के मुख्य अनुभव को प्रभावित नहीं करते हैं। चूंकि परिभाषा के अनुसार सॉफ्टवेयर उत्पादों में किसी भी संख्या में अज्ञात बग मौजूद हो सकते हैं, परीक्षण के दौरान मापन से बचे हुए संभावित बगों की संख्या का एक अनुमान प्राप्त किया जा सकता है; उत्पाद को जितनी देर तक परीक्षण या विकसित किया जाता है वह और अधिक विश्वसनीय हो जाता है ("अगर हमारे पास पिछले सप्ताह 200 बग थे तो इस सप्ताह हमारे पास 100 बग होने चाहिएं). ज्यादातर बड़ी सॉफ्टवेयर परियोजनाओं के पास "ज्ञात बग" की दो सूचियां होती हैं - एक वह जिसके बारे में सॉफ्टवेयर टीम को जानकारी होती है और दूसरी जिसके बारे में उपयोगकर्ताओं को बताया जाता है। यह तथ्यों का छिपाया जाना नहीं है बल्कि उपयोगकर्ता उत्पाद के आंतरिक कार्यप्रणाली पर ध्यान नहीं देते हैं। दूसरी सूची उपयोगकर्ताओं को उन बगों के बारे में जानकारी देती है जिन्हें मौजूदा रिलीज में या बिलकुल भी दूर नहीं किया गया है और एक वर्कअराउंड की पेशकश भी की जा सकती है।
बगों को दूर नहीं किये जाने के कई कारण होते हैं:
उपरोक्त को देखते हुए किसी वास्तविक जटिलता वाले एक पूरी तरह से बग-मुक्त सॉफ्टवेयर का लेखन अक्सर असंभव माना जाता है। इस प्रकार बगों को इनकी गंभीरता के आधार पर वर्गीकृत किया जाता है और कम-तीव्रता वाले गैर-गंभीर बगों को बर्दाश्त कर लिया जाता है क्योंकि वे अधिकांश उपयोगकर्ताओं के लिए सिस्टम के समुचित संचालन को प्रभावित नहीं करते हैं। नासा के एसएटीसी ने त्रुटियों की संख्या प्रति 1000 लाइनों के कोड (एसएलओसी) में 0.1 से भी कम करने में कामयाबी हासिल की थी लेकिन इसे किसी वास्तविक दुनिया के प्रोजेक्ट के लिए संभव नहीं समझा गया।
किसी बग की गंभीरता इसके ठीक करने के महत्त्व के बराबर नहीं होती है और दोनों का मापन और प्रबंधन अलग-अलग किया जाना चाहिए। एक माइक्रोसॉफ्ट विंडोज सिस्टम पर मौत का नीला स्क्रीन अपेक्षाकृत एक गंभीर होता है लेकिन अगर यह केवल चरम परिस्थितियों में होता है, खास तौर पर अगर ये अच्छी तरह उपचारित और परिहार्य होते हैं, किसी आइकन द्वारा अपने कार्य का सही प्रतिधिनित्व नहीं किये जाने की तुलना में इसमें सुधार किया जाना कम महत्वपूर्ण हो सकता है जो हालांकि पूरी तरह सौंदर्य से संबंधित है लेकिन यह हर दिन हजारों उपयोगकर्ताओं को भ्रमित कर सकता है। यह संतुलन ज़ाहिर तौर पर कई कारकों पर निर्भर करता है; विशेषज्ञ उपयोगकर्ताओं को नौसिखियों से अलग उम्मीदें रहती हैं, एक ऊँचे दर्जे का बाजार एक सामान्य उपभोक्ता बाजार और इसी तरह के अन्य बाजारों से अलग होता है। एक बेहतर संतुलन प्राप्त करने के लिए कुछ सॉफ्टवेयर डेवलपर एक औपचारिक "बग ट्राइएज" प्रक्रिया (चिकित्सा शब्दावली को लेकर) का उपयोग करते हैं जिसमें प्रत्येक नए बग को इसकी गंभीरता, आवृत्ति, जोखिम और अन्य पूर्व-निर्धारित कारकों के आधार पर एक प्राथमिकता दी जाती है।
एरिक एस. रेमंड द्वारा लाइनस लॉ के रूप में प्रचारित एक विचारधारा कहती है कि अन्य सॉफ्टवेयर की तुलना में लोकप्रिय ओपन-सोर्स सॉफ्टवेयर में कम या कोई बग नहीं होने के मौके ज्यादा होते हैं क्योंकि "अधिक ध्यान देने पर, सभी बग हल्के होते हैं". इस दावे को विवादित करार दिया गया है, हालांकि: कंप्यूटर सुरक्षा विशेषज्ञ एलियास लेवी ने लिखा है कि "जटिल, कम स्पष्ट और अप्रलेखित स्रोत कोड में कमजोरियों को छिपाना कहीं आसान होता है" क्योंकि "यहां तक कि अगर लोग कोड की समीक्षा करते है तो इसका मतलब यह नहीं होता है कि वे ऐसा करने के लिए योग्य होते हैं।"
इंजीनियरिंग प्रबंधन के किसी अन्य भाग की तरह बग प्रबंधन सावधानी पूर्वक और समझदारी से किया जाना चाहिए क्योंकि "जिसका मापन होता है उसे ही ठीक किया जाता है"  और शुद्ध रूप से बगों की गिनती द्वारा प्रबंधन अनपेक्षित परिणाम दे सकता है। उदाहरण के लिए, अगर डेवलपरों को उनके द्वारा ठीक किये गए बगों की संख्या के आधार पर पुरस्कृत किया जाता है तो वे स्वाभाविक रूप से -- सबसे कठिन और संभवतः सबसे जोखिमपूर्ण और सबसे महत्वपूर्ण बग को अंतिम संभव पलों के लिए छोड़कर सबसे आसान बग को पहले ठीक करेंगे ("मेरे पास अपनी सूची में एक मात्र बग है लेकिन यह "सूरज को पश्चिम से उगाने" की बात करता है). अगर प्रबंधन की प्रवृत्ति ठीक किये गए बगों के आधार पर पुरस्कृत करने की है तो कुछ डेवलेपर यह जानते हुए भी कि वे इन बगों को बाद में ठीक कर सकते हैं और इसके लिए पुरस्कृत किये जा सकते हैं, शीघ्रता से लापरवाह कोड लिख सकते हैं जबकि सावधान, संभवतः "धीमे" डेवलपरों को उन बगों के लिए कभी पुरस्कृत नहीं किया जाता है जो वहां कभी मौजूद ही नहीं थे।
दुर्भावनापूर्ण सॉफ्टवेयर किसी सिस्टम में ज्ञात कमजोरियों का फायदा उठाने की कोशिश कर सकते हैं - जो बग हो सकते हैं और नहीं भी हो सकते हैं। वायरस अपने आप में बग नहीं होते हैं - वे आम तौर पर प्रोग्राम होते हैं जो साफ़ तौर पर वही करते हैं जिनके लिए उन्हें डिजाइन किया गया होता है। हालांकि वायरसों को लोकप्रिय प्रेस में कभी-कभी इसी रूप में संदर्भित किया जाता है।