सॉफ्टवेयर परीक्षण
सॉफ्टवेयर परीक्षण एक अनुभवजन्य खोज है, जिसके तहत हितधारकों को परीक्षणाधीन उत्पाद या सेवा की गुणवत्ता के बारे में, उस संदर्भ में जानकारी उपलब्ध कराई जाती है, जहाँ इसे प्रयोग के लिए नियत किया गया है। सॉफ्टवेयर परीक्षण, उद्योग को सॉफ्टवेयर के कार्यान्वयन में जोखिम को समझने और सराहना करने की अनुमति देने के लिए, सॉफ्टवेयर का उद्देश्य और स्वतंत्र अवलोकन भी प्रदान करता है। टेस्ट तकनीकों में शामिल है, लेकिन इतने तक ही सीमित नहीं, सॉफ्टवेयर बग खोजने के इरादे से एक प्रोग्राम या अनुप्रयोग के निष्पादन की प्रक्रिया।
यह भी कहा जा सकता है कि सॉफ्टवेयर परीक्षण वह प्रक्रिया है, जो यह विधिमान्य और सत्यापित करती है कि एक सॉफ्टवेयर प्रोग्राम/अनुप्रयोग/उत्पाद:कार्यरत परीक्षण पद्धति के आधार पर, सॉफ्टवेयर परीक्षण को विकास की प्रक्रिया में किसी भी समय लागू किया जा सकता है। बहरहाल, टेस्ट के अधिकांश प्रयास तब शुरू होते हैं, जब आवश्यकताओं को परिभाषित कर दिया गया हो और कोडिंग प्रक्रिया पूर्ण हो गई हो। विभिन्न सॉफ्टवेयर विकास मॉडल, विकास की प्रक्रिया में परीक्षण प्रयास को विभिन्न चरणों पर केन्द्रित करते हैं। एक अधिक पारंपरिक मॉडल में, परीक्षण के अधिकांश प्रयास तब शुरू होते हैं, जब आवश्यकताओं को परिभाषित कर दिया गया हो और कोडिंग प्रक्रिया पूर्ण हो गई हो। अपेक्षाकृत नए विकास मॉडल, जैसे Agile या XP, अक्सर विकास संचालित परीक्षण का प्रयोग करते हैं और विकास की प्रक्रिया में परीक्षण का ज्यादा हिस्सा, डेवलपर को सौंपते हैं।
परीक्षण, पूरी तरह से सॉफ्टवेयर के भीतर सभी दोषों की पहचान नहीं कर सकता है। इसके बजाय, यह एक "आलोचना" या "तुलना" प्रस्तुत करता है, जो प्रामाणिक- सिद्धांत या व्यवस्था के प्रति, जिसके द्वारा एक व्यक्ति किसी समस्या को पहचान सकता है - उत्पाद की स्थिति और व्यवहार की तुलना करता है। इन प्रामाणिकताओं में शामिल हो सकते हैं (लेकिन यहीं तक सीमित नहीं है) विनिर्देशन, अनुबन्ध, तुलनीय उत्पाद, उसी उत्पाद का पिछला संस्करण, नियत या अपेक्षित उद्देश्यों का अनुमान, उपयोगकर्ता या ग्राहक की अपेक्षाएं, उपयुक्त मानक, प्रयोज्य नियम, या अन्य मानदंड।
हर सॉफ्टवेयर उत्पाद के लक्षित दर्शक होते हैं। उदाहरण के लिए, वीडियो गेम सॉफ़्टवेयर के दर्शक, बैंकिंग सॉफ्टवेयर से पूरी तरह से अलग है। इसलिए, जब एक संगठन किसी सॉफ्टवेयर उत्पाद को विकसित अथवा उसमें निवेश करता है, तो वह यह आकलन कर सकता है कि सॉफ्टवेयर उत्पाद अपने अन्तिम उपयोगकर्ताओं, अपने लक्षित दर्शकों, अपने खरीदारों और अन्य हितधारकों को स्वीकार्य होगा या नहीं। सॉफ्टवेयर परीक्षण इस मूल्यांकन के प्रयास की प्रक्रिया है।
2002 में NIST द्वारा किए गए एक अध्ययन से यह पता चलता है कि सॉफ्टवेयर बग से अमेरिकी अर्थव्यवस्था को सालाना $59.5 बीलियन की चपत लगती है। यदि बेहतर सॉफ्टवेयर परीक्षण की जाए, तो इस लागत का एक तिहाई हिस्सा बचाया जा सकता है।
प्रारंभ में परीक्षण से डीबगिंग के पृथक्करण को ग्लेन्फोर्ड जे. मायर्स द्वारा 1979 में प्रवर्तित किया गया। हालांकि उनका ध्यान ब्रेकेज परीक्षण पर था ("एक सफल परीक्षण वह है, जो एक बग को खोजती है") इसने सॉफ्टवेयर इंजीनियरिंग समुदाय की बुनियादी विकास गतिविधियों, जैसे डीबगिंग को सत्यापन से अलग करने की इच्छा की पुष्टि की। डेव गेल्परिन और विलियम सी. हेत्ज़ेल ने 1988 में सॉफ्टवेयर परीक्षण में प्रावस्थाओं और लक्ष्यों को निम्नलिखित चरणों में वर्गीकृत किया है:परीक्षण का एक प्राथमिक उद्देश्य, सॉफ्टवेयर विफलताओं का पता लगाना है, ताकि दोषों को खोजा और सुधारा जा सके। यह एक गैर-नगण्य खोज है। परीक्षण यह स्थापित नहीं कर सकता कि एक उत्पाद सभी परिस्थितियों में ठीक-ठीक कार्य कर रहा है, पर सिर्फ इतना स्थापित कर सकता है कि यह किन विशिष्ट परिस्थितियों में ठीक-ठीक काम नहीं करता है। सॉफ्टवेयर परीक्षण के कार्यक्षेत्र में अक्सर कोड की परीक्षा के अलावा विभिन्न वातावरण और परिस्थितियों में उस कोड का निष्पादन, साथ ही, उस कोड के पहलुओं की जांच शामिल है: क्या यह वह कार्य करता है जो इसे करना चाहिए और क्या यह, वह करता जो इसे करने की ज़रूरत है। सॉफ्टवेयर विकास की वर्तमान संस्कृति में एक परीक्षण संगठन, विकास दल से अलग हो सकता है। परीक्षण दल के सदस्यों के लिए विभिन्न भूमिकाएं होतीं हैं। सॉफ्टवेयर परीक्षण से प्राप्त जानकारी का प्रयोग, उस प्रक्रिया को सही करने के लिए किया जा सकता है, जिसके द्वारा सॉफ्टवेयर का विकास किया गया है।
फंक्शनल परीक्षण उस परीक्षण से संबन्ध रखता है, जो कोड की एक विशिष्ट कार्रवाई या प्रकार्य को सत्यापित करता है। ये आम तौर पर कोड की आवश्यकताओं के प्रलेखन में पाया जाता है, हालांकि कुछ विकास प्रक्रिया, प्रयुक्त मामले या उपयोगकर्ता ख़बरों से काम करते हैं। फंक्शनल टेस्ट इस सवाल का जवाब देते हैं कि "क्या उपयोगकर्ता इसे कर सकता है" या "क्या यह विशेष सुविधा काम करती है"।
नॉन-फंक्शनल परीक्षण, सॉफ्टवेयर के उन पहलुओं को दर्शाता है, जो संभव है कि किसी विशेष प्रकार्य या उपयोगकर्ता की क्रिया, जैसे आरोहण या सुरक्षा से संबन्धित ना हों. नॉन-फंक्शनल परीक्षण इस तरह के सवालों का जवाब देता है कि "एक बार में कितने लोग लॉग इन कर सकते हैं", या "इस सॉफ्टवेयर को हैक करना कितना आसान है"।
सॉफ्टवेयर के सभी दोष, कोड की त्रुटियों के कारण नहीं होते हैं। महंगे दोषों का एक आम स्रोत, अपेक्षाओं के अन्तराल के कारण पनपता है, उदाहरण है, अपरिचित अपेक्षाएं, जो प्रोग्राम डिजाइनर द्वारा विलोपन की त्रुटियों में फलित होते हैं। अपेक्षा अन्तराल का एक आम स्रोत, ग़ैर-कार्यात्मक अपेक्षा है, जैसे परीक्षण-क्षमता, आरोहण-क्षमता, अनुरक्षण-क्षमता, उपयोग-क्षमता, निष्पादन और सुरक्षा।
सॉफ्टवेयर दोष निम्नलिखित प्रक्रियाओं के माध्यम से होते हैं। प्रोग्रामर एक त्रुटि (ग़लती) करता है, जो सॉफ्टवेयर के सोर्स कोड में एक ख़राबी (दोष, बग) में फलित होता है। यदि इस ख़राबी को निष्पादित किया जाता है, तो कुछ ख़ास स्थितियों में सिस्टम त्रुटिपुर्ण परिणाम देगा, जो एक विफलता का कारण बनेगा। सभी दोष आवश्यक रूप से विफलता में परिणत नहीं होंगे। उदाहरण के लिए, डेड कोड में दोष, कभी विफलता में परिणत नहीं होंगे। जब परिवेश बदला जाता है, तब एक ख़राबी विफलता में बदल सकती है। परिवेशगत इन परिवर्तनों के उदाहरणों में शामिल हैं, सॉफ्टवेयर का एक नए हार्डवेयर प्लेटफोर्म पर चलाया जाना, सोर्स डाटा में परिवर्तन या भिन्न सॉफ्टवेयर के साथ पारस्परिक क्रिया. एक एकल त्रुटि, विफलता के विस्तृत लक्षण में परिणत हो सकती है।
आम तौर पर यह माना जाता है कि एक ख़राबी को जितना पहले खोजा जाए, उसे ठीक करना उतना ही सस्ता होता है।  निम्नलिखित तालिका, ख़राबी के पता लगाए जाने वाले चरण के आधार पर, उसे ठीक करने की लागत को दर्शाती है। उदाहरण के लिए, यदि अपेक्षाओं में कोई समस्या सिर्फ रिलीज़ के बाद सामने आती है, तो इसका खर्चा अपेक्षाओं की समीक्षा द्वारा ही पता लगा लिए जाने के खर्चे से 10-100 गुणा अधिक होगा।
सॉफ्टवेयर विफलता का एक आम कारण, अन्य अनुप्रयोग, एक नए ऑपरेटिंग सिस्टम, या, बढ़ते हुए वेब ब्राउज़र संस्करण के साथ संगतता है। पश्च संगतता की कमी के मामले में, यह (उदाहरण के लिए। ..) इसलिए हो सकता है, क्योंकि प्रोग्रामर ने अपने प्रोग्राम की कोडिंग या सॉफ्टवेयर का परीक्षण सिर्फ़, इस-और-उस ऑपरेटिंग सिस्टम "के "नवीनतम" संस्करण" पर करने का विचार किया। इस तथ्य का अनायास नतीजा यह है कि: उनका नवीनतम कार्य, सॉफ्टवेयर/हार्डवेयर के पूर्व मिश्रण के साथ पूरी तरह से संगत नहीं भी हो सकता है, या यह "एक अन्य" महत्वपूर्ण ऑपरेटिंग सिस्टम के साथ पूरी तरह से संगत नहीं हो सकता है। किसी भी स्थिति में, ये मतभेद, वे जो भी हों, (अनपेक्षित...) सॉफ्टवेयर विफलता में परिणत हुए होंगे, जैसा कि कंप्यूटर प्रयोक्ताओं के कुछ महत्वपूर्ण तबके ने महसूस किया।
इसे एक "सुरक्षा उन्मुख रणनीति" मान सकते हैं, जो कि डेव गेल्परिन और विलियम सी. हेत्ज़ेल द्वारा सुझाए नवीनतम परिक्षण चरण के साथ सटीक बैठता है, जैसा कि नीचे उद्धृत है।.
सॉफ्टवेयर परीक्षण के साथ एक मुख्य समस्या है कि इनपुट और प्री-कंडीशन (प्रारम्भिक स्थिति) के "सारे" कॉम्बिनेशन के अन्तर्गत परीक्षण संभव नहीं है, यहाँ तक कि एक सामान्य उत्पाद के साथ भी नहीं। इसका मतलब है कि सॉफ्टवेयर उत्पाद में दोषों की संख्या काफी अधिक हो सकती हैं और जो दोष कभी-कभी होते हैं उन्हें परीक्षण में खोजना मुश्किल है। अधिक महत्वपूर्ण रूप से, गुणवत्ता के ग़ैर-कार्यात्मक आयाम (इसे कैसा "होना" चाहिए बनाम इसे क्या "करना" चाहिए)- उपयोग-क्षमता, आरोहण-क्षमता, निष्पादन, संगतता, विश्वसनीयता-अत्यंत व्यक्तिपरक हो सकते हैं; कुछ ऐसा, जो एक व्यक्ति के लिए पर्याप्त मूल्य का गठन करता है, जो दूसरे के लिए असहनीय है।
सॉफ्टवेयर परीक्षण के लिए कई दृष्टिकोण हैं। समीक्षा, आर-पार गुज़ारना, या निरीक्षण को स्टैटिक परीक्षण माना जाता है, जबकि दिए गए एक परीक्षण मामले के सेट के साथ वास्तविक निष्पादित प्रोग्राम कोड डाइनेमिक परीक्षण माना जाता है। स्टैटिक परीक्षण को (और दुर्भाग्य से व्यवहार में अक्सर जैसा होता है) छोड़ा जा सकता है। डाइनेमिक परीक्षण तब प्रयुक्त होता है, जब खुद प्रोग्राम को ही पहली बार प्रयोग किया जा रहा हो (जिसे आम तौर पर परीक्षण चरण की शुरूआत माना जाता है)। डाइनेमिक परीक्षण, प्रोग्राम के 100% पूर्ण होने से पहले कोड के विशेष हिस्सों के परीक्षण के लिए शुरू हो सकती है (मॉड्यूल या डिस्क्रीट फंक्शन)। इसके लिए विशिष्ट तकनीक हैं स्टब्स/ड्राइवर्स का प्रयोग करना या फिर एक डिबगर परिवेश से निष्पादन. उदाहरण के लिए, स्प्रेडशीट प्रोग्राम, खुद अपनी प्रकृति द्वारा, काफी हद तक परस्पर रूप से ("ऑन द फ्लाई") जांचे जाते हैं, जिसके तहत परिणाम, प्रत्येक गणना या टेक्स्ट परिचालन के तुरंत बाद प्रदर्शित होते हैं।
सॉफ्टवेयर परीक्षण का प्रयोग सत्यापन और प्रमाणीकरण के साहचर्य से किया जाता है:सत्यापन और प्रमाणीकरण शब्द का आम तौर पर प्रयोग, उद्योग में अन्तर-परिवर्तनशीलता से किया जाता है; इन दोनों शब्दों को ग़लत तरीके से परिभाषित करना भी आम है। IEEE सॉफ्टवेयर इंजीनियरिंग की मानक शब्दावली के अनुसार:
सॉफ्टवेयर परीक्षण "सॉफ्टवेयर टेस्टर" द्वारा की जा सकती है। 1980 के दशक तक शब्द "सॉफ्टवेयर टेस्टर" को आम तौर पर इस्तेमाल किया जाता था, लेकिन बाद में इसे एक अलग व्यवसाय के रूप में देखा गया। सॉफ्टवेयर परीक्षण में अवधियों और विभिन्न लक्ष्यों से संबन्धित विभिन्न भूमिकाओं को स्थापित किया गया है: "मैनेजर", "टेस्ट लीड", "टेस्ट डिजाइनर", "टेस्टर", "ऑटोमेशन डेवलपर" और "टेस्ट एडमिनिसट्रेटर"
हालांकि विवादास्पद, सॉफ्टवेयर परीक्षण को सॉफ्टवेयर क्वालिटी अश्युरेन्स (SQA) प्रक्रिया के एक महत्वपूर्ण हिस्से के रूप में देखा जा सकता है। SQA में, सॉफ्टवेयर प्रक्रिया विशेषज्ञ और लेखा परीक्षक, सॉफ्टवेयर और उसके विकास पर एक व्यापक दृष्टिकोण रखते हैं। वे सॉफ्टवेयर इंजीनियरिंग प्रक्रिया की जांच करते हैं और प्रदत्त सॉफ्टवेयर में मौजूद दोषों: तथाकथित "दोष दर" की मात्रा को कम करने के लिए उसे ही बदल देते हैं।
एक "स्वीकार्य दोष दर" का गठन करने वाली चीज़ें सॉफ्टवेयर की प्रकृति पर निर्भर करती हैं। उदाहरण के लिए, एक आर्केड वीडियो गेम में, जिसे एक हवाई जहाज उड़ाने का "आभास" देने के लिए डिज़ाइन किया गया है, संभवतः दोषों के प्रति अपेक्षाकृत अधिक सहनशीलता होगी, उस मिशन क्रिटिकल सॉफ्टवेयर की तुलना में, जिसका उपयोग एक एयरलाइनर को नियंत्रित करने में होता है, जो "वास्तव में" उड़ रहा है।
यद्यपि SQA के साथ घनिष्ठ संबन्ध हैं, परीक्षण विभाग अक्सर स्वतंत्र रूप से कार्य करते हैं और हो सकता है कि किसी कंपनी में SQA का कोई कार्य ना हो।
सॉफ्टवेयर परीक्षण, एक कंप्यूटर प्रोग्राम के अपेक्षित परिणामों को, दिए गए एक इनपुट सेट के लिए, इसके वास्तविक परिणामों से तुलना करते हुए, सॉफ्टवेयर में दोषों का पता लगाने के उद्देश्य से किया गया कार्य है। विरोधाभास स्वरूप, QA (क्वालिटी अश्युरेन्स), दरअसल होने वाली त्रुटियों को रोकने के उद्देश्य से नीतियों और प्रक्रियाओं का कार्यान्वयन है।
सॉफ्टवेयर परीक्षण तरीक़ों को परंपरागत रूप से ब्लैक बॉक्स परीक्षण और व्हाईट बॉक्स परीक्षण में विभाजित किया गया हैं। इन दोनों अभिगमों का प्रयोग उस दृष्टिकोण के वर्णन के लिए किया जाता है, जो एक टेस्ट इंजीनियर टेस्ट मामलों की डिजाइनिंग के लिए अपनाता है।
ब्लैक बॉक्स परीक्षण, सॉफ्टवेयर से एक "ब्लैक बॉक्स" के रूप में व्यवहार करता है - बिना किसी आंतरिक कार्यान्वयन की जानकारी के ब्लैक बॉक्स परीक्षण तरीकों में शामिल हैं: इक्विवेलेंस पार्टिशनिंग, बाउंड्री वैल्यू एनैलिसिस, ऑल पेयर्स परीक्षण, फ़ज परीक्षण, मॉडल-बेस्ड परीक्षण, ट्रेसेबिलिटी मेट्रिक्स, एक्स्प्लोरेटरी परीक्षण और स्पेसीफिकेशन-आधारित परीक्षण।
इसलिए, ब्लैक बॉक्स परीक्षण में एक ओर "एक असम्बद्ध राय" का फायदा है और दूसरी ओर "अंधी तलाश" का नुक्सान। व्हाइट बॉक्स परीक्षण तब होती है जब परीक्षक के पास, आंतरिक डाटा संरचनाओं और इसे लागू करने वाले कोड सहित एल्गोरिदम तक पहुंच सुलभ होती है। वे दोनों एक कोड कवरेज मीट्रिक को लौटाते हैं, जिसे प्रतिशत के रूप में मापा जाता है।
ग्रे बॉक्स परीक्षण में शामिल है आंतरिक डाटा संरचनाओं और एल्गोरिदम तक, परीक्षण मामलों को डिजाइन करने के लिए पहुंच, लेकिन उपयोगकर्ता, या ब्लैक बॉक्स स्तर पर परीक्षण. इनपुट डाटा का परिवर्तन और आउटपुट को फोर्मेट करना, ग्रे बॉक्स के तहत नहीं आता, क्योंकि इनपुट और आउटपुट उस "ब्लैक-बॉक्स" से स्पष्ट रूप से बाहर है, जिसे हम परीक्षण के तहत सिस्टम कह रहे हैं। यह अन्तर विशेष रूप से तब महत्वपूर्ण है, जब दो अलग डेवलपर्स द्वारा लिखे कोड के दो मॉड्यूलों के बीच इंटीग्रेशन परीक्षण सम्पादित की जाती है, जहाँ परीक्षण के लिए सिर्फ़ इंटरफेस को प्रस्तुत किया जाता है। हालांकि, एक डाटा भंडार को संशोधित करना ज़रूर ग्रे बॉक्स के अन्तर्गत आता है, चूंकि आम तौर पर उपयोगकर्ता परीक्षण के तहत सिस्टम के बाहर डाटा बदलने में सक्षम नहीं होगा। ग्रे बॉक्स परीक्षण में रिवर्स इंजीनियरिंग भी शामिल हो सकती है, उदाहरण के लिए, बाउंडरी वैल्यू या त्रुटि संदेश निर्धारित करने के लिए।
परीक्षणों को अक्सर, सॉफ्टवेयर विकास प्रक्रिया में उनके शामिल होने की जगह के आधार पर वर्गीकृत किया जाता है, या परीक्षण की विशिष्टता के स्तर द्वारा।
यूनिट परीक्षण उन परीक्षणों को संदर्भित करता है, जो कोड के एक विशेष खंड की कार्यशीलता, आम तौर पर प्रक्रिया स्तर पर, सत्यापित करते हैं। एक ऑब्जेक्ट-उन्मुख परिवेश में, यह अक्सर श्रेणी स्तर पर होता है और न्यूनतम इकाई परीक्षण में शामिल होता है कंस्ट्रक्टर और डिस्ट्रक्टर।
इस प्रकार के परीक्षण आम तौर पर डेवलपर्स द्वारा लिखे जाते हैं, जब वे कोड पर काम कर रहे होते हैं (व्हाइट बॉक्स शैली), यह सुनिश्चित करने के लिए कि एक विशेष प्रक्रिया अपेक्षानुरूप ठीक ढंग से काम कर रही है। कोड में कॉर्नर केसेस या अन्य शाखाओं को पकड़ने के लिए, एक प्रक्रिया में कई परीक्षण हो सकते हैं। यूनिट परीक्षण अकेले, सॉफ्टवेयर के एक अंश की कार्यक्षमता को सत्यापित नहीं कर सकती, बल्कि इसका प्रयोग यह सुनिश्चित करने के लिए होता है कि सॉफ्टवेयर द्वारा प्रयुक्त बिल्डिंग ब्लॉक, एक दूसरे से स्वतंत्र रूप से कार्य करते हैं।
इंटीग्रेशन परीक्षण किसी भी प्रकार का सॉफ्टवेयर परीक्षण है, जो एक सॉफ्टवेयर डिजाइन के प्रति घटकों के बीच इंटरफेस को सत्यापित करने का प्रयास करता है। सॉफ्टवेयर घटक को, पुनरावृत्तीय तरीक़े से या एक साथ ("बिग बैंग") एकीकृत किया जा सकता है। आम तौर पर पहले वाले तरीक़े को एक बेहतर अभ्यास माना जाता है, चूंकि यह इंटरफ़ेस मुद्दों को त्वरित रूप से स्थानीय होने और ठीक होने की अनुमति देता है।
इंटीग्रेशन परीक्षण, इंटरफेस में त्रुटियाँ उजागर करने और एकीकृत घटक (मॉड्यूल) के बीच पारस्परिक क्रिया को दर्शाने के लिए काम करता है। उत्तरोत्तर, आर्कीटेक्चरल डिजाइन के तत्वों के अनुरूप जांचे गए सॉफ्टवेयर घटकों के बड़े समूहों को एकीकृत और तब तक जांचा जाता है, जब तक सॉफ्टवेयर एक सिस्टम के रूप में काम ना करने लगे।
सिस्टम परीक्षण यह सत्यापित करने के लिए एक पूरी तरह से एकीकृत सिस्टम का परीक्षण करता है कि वह अपनी आवश्यकताओं को पूरा करता है।
सिस्टम इंटीग्रेशन परीक्षण यह पुष्टि करता है कि एक सिस्टम, सिस्टम आवश्यकताओं में परिभाषित किसी भी बाहरी या अन्य पक्ष के सिस्टम से एकीकृत है।
रिग्रेशन परीक्षण एक प्रमुख कोड परिवर्तन के बाद दोषों को खोजने पर ध्यान केंद्रित करता है। विशेष रूप से, यह सॉफ्टवेयर प्रतिगमन को या पुराने बग जो वापस आ गए हैं, उन्हें उजागर करने का प्रयास करता है। जब भी सॉफ्टवेयर प्रक्रिया, जो पहले सही ढंग से काम कर रही थी और अब अपेक्षानुसार कार्य करना बंद कर दे, तब ऐसे प्रतिगमन घटित होते हैं। विशिष्ट रूप से, प्रतिगमन, प्रोग्राम परिवर्तन के एक अनपेक्षित परिणाम के रूप में घटित होते हैं, जब सॉफ्टवेयर का नव विकसित हिस्सा, पहले से मौजूद कोड के साथ टकराता है। रिग्रेशन परीक्षण के आम तरीकों में शामिल है, पहले चलाए गए परीक्षण को फिर से चलाना और जांच करना कि पहले ठीक की गई खराबियाँ कहीं फिर से उभर तो नहीं आई हैं। परीक्षण की गहराई, जारी प्रक्रिया में चरण पर निर्भर करती है और अतिरिक्त विशेषताओं के जोखिम पर. वे या तो पूर्ण हो सकते हैं, रिलीज़ में काफी देर से जोड़े गए परिवर्तनों के लिए या फिर जोखिम भरे, बहुत उथले तक, प्रत्येक सुविधा पर सकारात्मक परीक्षण से बने हुए, अगर बदलाव, रिलीज में जल्दी हो रहे हैं या कम जोखिम वाले समझे जाते हैं।
एक्सेपटेंस परीक्षण का तात्पर्य दो में से एक से हो सकता है:"अल्फा परीक्षण", संभावित उपयोगकर्ताओं/ग्राहकों या डेवलपर की साइट पर एक स्वतंत्र टेस्ट टीम द्वारा नकली या वास्तविक संचालन परीक्षण है। सॉफ्टवेयर के बीटा परीक्षण में जाने से पहले, अल्फा परीक्षण को अक्सर ऑफ़-द-शेल्फ सॉफ्टवेयर के लिए आंतरिक स्वीकृति परीक्षण के एक रूप में प्रयोग किया जाता है।
"बीटा परीक्षण" अल्फा परीक्षण के बाद आता है। बीटा संस्करण के नाम से विख्यात सॉफ्टवेयर का संस्करण, प्रोग्रामिंग टीम से बाहर एक सीमित ग्राहकों के लिए जारी किया गया। सॉफ्टवेयर को लोगों के समूहों के लिए जारी किया जाता है, ताकि आगे के परीक्षण यह सुनिश्चित कर सकें कि उत्पाद में न्यूनतम खराबियाँ या बग हैं। कभी-कभी, बीटा संस्करण को भावी उपयोगकर्ताओं की अधिकतम संख्या को प्रतिक्रिया के क्षेत्र को बढाने के लिए, खुली जनता के लिए उपलब्ध कराया जाता है।
सॉफ्टवेयर के ग़ैर-कार्यात्मक पहलुओं के परीक्षण के लिए विशेष तरीक़े मौजूद हैं। कार्यात्मक परीक्षण के विपरीत, जो सॉफ़्टवेयर के सही संचालन को स्थापित करता है (सही इस मायने में कि यह डिजाइन आवश्यकताओं में परिभाषित अपेक्षित व्यवहार से मेल खाता है), ग़ैर-कार्यात्मक परीक्षण इस बात की पुष्टि करता है कि सॉफ्टवेयर तब भी ठीक ढंग से कार्य करता है, जब इसे अवैध या अप्रत्याशित इनपुट प्राप्त होती है। सॉफ्टवेयर फॉल्ट इंजेक्शन, फजिंग के रूप में, एक ग़ैर-कार्यात्मक परीक्षण का उदाहरण है। ग़ैर-कार्यात्मक परीक्षण, विशेष रूप से सॉफ्टवेयर की खातिर, यह स्थापित करने के लिए डिज़ाइन किया गया है कि परीक्षण के अन्तर्गत रचना, अवैध या अनपेक्षित इनपुट को सहन कर सकती है या नहीं और इस प्रकार वे इनपुट वैलीडेशन रूटीन और साथ ही साथ एरर-हैंडलिंग रूटीन की मजबूती को स्थापित कर सकेंगे। विभिन्न वाणिज्यिक ग़ैर-कार्यात्मक परीक्षण उपकरण, सॉफ्टवेयर फॉल्ट इंजेक्शन पृष्ठ से जुड़े होते हैं; कई खुले स्रोत के और मुफ्त सॉफ्टवेयर उपकरण उपलब्ध हैं, जो ग़ैर-कार्यात्मक परीक्षण करते हैं।
परफोर्मेंस परीक्षण, या लोड परीक्षण यह देखने के लिए जांच करता है कि सॉफ्टवेयर, बड़ी मात्रा में डाटा या उपयोगकर्ताओं को संभाल सकता है या नहीं। आम तौर पर इसे सॉफ्टवेयर स्केलेबिलिटी के रूप में जाना जाता है। ग़ैर-कार्यात्मक सॉफ्टवेयर परीक्षण की यह गतिविधि अक्सर क्षमता परीक्षा के रूप में जानी जाती है।
स्थाईत्व परीक्षण यह देखने के लिए जांच करता है कि सॉफ्टवेयर एक स्वीकार्य अवधि में या उससे ऊपर, लगातार अच्छी तरह से कार्य करता सकता है या नहीं। ग़ैर-कार्यात्मक सॉफ्टवेयर परीक्षण की यह गतिविधि अक्सर लोड (या एंड्युरेंस) परीक्षण के रूप में निर्दिष्ट होती है।
प्रयोज्यता परीक्षण की जरूरत यह जांचने के लिए होती है कि यूज़र इंटरफ़ेस का उपयोग करना और उसे समझना आसान है या नहीं।
सुरक्षा परीक्षण उस सॉफ्टवेयर के लिए जरूरी है जो हैकर्स द्वारा सिस्टम घुसपैठ को रोकने के लिए गोपनीय डाटा को परिष्कृत करता है।
अन्तर्राष्ट्रीयकरण और स्थानीयकरण की जरूरत सॉफ्टवेयर के इन पहलुओं की जांच के लिए होती है, जिसके लिए एक छद्मस्थानीयकरण विधि का इस्तेमाल किया जा सकता है। यह इस बात की पुष्टि करेगा कि अनुप्रयोग, एक नई भाषा में अनुवाद किए जाने या एक नई संस्कृति के लिए अनुकूलित किये जाने के बाद भी (जैसे विभिन्न मुद्राएं या समय क्षेत्र) काम करता है।
विनाशक परीक्षण, सॉफ्टवेयर या उप-प्रणाली को इसकी मजबूती के जांच के लिए, विफल करने का प्रयास करती है।
सॉफ्टवेयर परीक्षण के एक आम तरीके को, इसे ग्राहक को भेजे जाने से पहले और इसकी कार्यक्षमता विकसित किये जाने के बाद, परीक्षकों के एक स्वतंत्र समूह द्वारा सम्पादित किया जाता है। इस अभ्यास के परिणामस्वरूप अक्सर परीक्षण चरण का, परियोजना में हुई देरी की क्षतिपूर्ति के लिए परियोजना बफर के रूप में उपयोग किया जाता है और इस प्रकार से परीक्षण के लिए समर्पित समय के साथ समझौता होता है। एक और परिपाटी है परियोजना के शुरू होने के क्षण ही सॉफ्टवेयर परीक्षण को शुरू कर देना और परियोजना के समापन तक यह एक सतत प्रक्रिया है।
जवाब में, कुछ ऐसे उभरते सॉफ्टवेयर विषय जैसे एक्सट्रीम प्रोग्रामिंग और एजाइल सॉफ्टवेयर डिवेलपमेंट आंदोलन, एक "टेस्ट ड्रिवेन सॉफ्टवेयर डेवेलपमेंट" मॉडल का पालन करते हैं। इस प्रक्रिया में, सॉफ्टवेयर इंजीनियर द्वारा यूनिट टेस्ट पहले लिखे जाते हैं, (अक्सर एक्सट्रीम प्रोग्रामिंग पद्धति में पेयर प्रोग्रामिंग के साथ). बेशक ये परीक्षण शुरू में विफल हो जाते हैं; जैसे कि उनसे उम्मीद रहती है। और फिर जैसे ही कोड लिखा जाता है यह परीक्षण स्वीट के बड़े अंश के संवर्द्धित रूप से गुजरता है। टेस्ट स्वीट को, विफलता की नई परिस्थितियों और कॉर्नर केस के मिलते रहने के कारण, लगातार नवीनीकृत किया जाता है और उन्हें किसी भी विकसित रिग्रेशन टेस्ट के साथ एकीकृत किया जाता है। बाकी सॉफ्टवेयर सोर्स कोड के साथ यूनिट टेस्ट को बनाए रखा जाता है और आम तौर पर बिल्ड प्रक्रिया में एकीकृत किया जाता है (जहाँ अन्तर्जात पारस्परिक क्रिया परीक्षण को आंशिक रूप से मानव निर्मित स्वीकृति प्रक्रिया में बदल दिया जाता है)।
हालांकि संगठनों के बीच भिन्नता मौजूद है, परीक्षण के लिए एक विशिष्ट चक्र होता है। निम्न नमूना, वॉटर फॉल डेवलपमेंट मॉडल को अपनाने वाले संगठनों के बीच आम है।कई प्रोग्रामिंग समूह, स्वचालित परीक्षण पर अधिकाधिक निर्भर कर रहे हैं, विशेष रूप से ऐसे समूह जो टेस्ट चालित विकास का उपयोग करते हैं। टेस्ट लिखने के कई फ्रेमवर्क हैं और सतत एकीकरण सॉफ्टवेयर, परीक्षण को स्वतः चलाएगा, जब हर बार कोड एक वर्ज़न कंट्रोल सिस्टम में परखा जाएगा।
जबकि स्वचालन वह सब कुछ निर्मित नहीं कर सकता, जो कि एक मानव कर सकता है (और वे अजीब तरीके, जिसे वे ऐसा करने की खातिर अपनाते हैं), यह रिग्रेशन परीक्षण के लिए बहुत उपयोगी हो सकते हैं। तथापि, वास्तव में उपयोगी होने के लिए, इसमें स्क्रिप्ट परीक्षण की एक पूर्ण विकसित टेस्ट स्वीट की आवश्यकता होती है।
प्रोग्राम परीक्षण और गड़बड़ी का पता लगाने में परीक्षण उपकरण और डिबगर द्वारा काफी सहायता प्राप्त हो सकती है।  परीक्षण/डिबग उपकरणों की विशेषताओं में शामिल हैं:इन गुणों में से कुछ को एक एकीकृत विकास परिवेश (IDE) में शामिल किया जा सकता है।
आम तौर पर, जिन विषयों तक गुणवत्ता सीमित होती है, वे हैं शुद्धता, संपूर्णता, सुरक्षा, लेकिन ISO मानक ISO 9126 के तहत वर्णित अधिक तकनीकी आवश्यकताएं भी शामिल हो सकती हैं, जैसे क्षमता, विश्वसनीयता, दक्षता, सुवाह्यता, रख-रखाव, संगतता और 0}प्रयोज्यता।
कई आम सॉफ्टवेयर उपाय मौजूद हैं, जिन्हें अक्सर 'मैट्रिक्स' कहा जाता है, जिनका प्रयोग सॉफ्टवेयर की हालत या परीक्षण की पर्याप्तता के मापन के लिए किया जाता है।
सॉफ्टवेयर परीक्षण प्रक्रिया कई आर्टीफैक्ट को उत्पन्न कर सकती है।सॉफ्टवेयर परीक्षकों और गुणवत्ता आश्वासन विशेषज्ञों की पेशेवर आकांक्षाओं को बल देने के लिए कई प्रमाणन कार्यक्रम मौजूद हैं। वर्तमान में प्रदान किये जाने वाले प्रमाणन में ऐसा कोई नहीं है, जिसमें वास्तव में आवेदक के लिए सॉफ्टवेयर परीक्षण की क्षमता को प्रदर्शित करने की आवश्यकता होती है। कोई भी प्रमाणीकरण, व्यापक रूप से स्वीकृत ज्ञान के ढांचे पर आधारित नहीं है। इस तथ्य ने कुछ लोगों को यह कहने के लिए प्रेरित किया कि परीक्षण क्षेत्र अभी प्रमाणन के लिए तैयार नहीं है। अकेले प्रमाणन एक व्यक्ति की उत्पादकता, उनके कौशल, या व्यावहारिक ज्ञान को माप नहीं सकता और एक परीक्षक के रूप में उनकी क्षमता, या पेशेवराना शैली की गारंटी नहीं दे सकता.
कुछ प्रमुख सॉफ्टवेयर परीक्षण विवादों में शामिल हैं: