सॉफ्टवेयर परिक्षण

सॉफ्टवेयर परीक्षण सत्यापन और सत्यापन द्वारा परीक्षण के तहत सॉफ्टवेयर के व्यवहार और कलाकृतियों की जांच करने का कार्य है। सॉफ़्टवेयर परीक्षण सॉफ़्टवेयर का एक उद्देश्यपूर्ण, स्वतंत्र दृश्य भी प्रदान कर सकता है जिससे व्यवसाय सॉफ़्टवेयर कार्यान्वयन के जोखिमों की सराहना और समझ सके। टेस्ट तकनीकों में शामिल हैं, लेकिन जरूरी नहीं कि ये सीमित हों:


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

सॉफ्टवेयर परीक्षण, सॉफ्टवेयर की गुणवत्ता और उपयोगकर्ताओं या प्रायोजकों को इसकी विफलता के जोखिम के बारे में उद्देश्यपूर्ण, स्वतंत्र जानकारी प्रदान कर सकता है।

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

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

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

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

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

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

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

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

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

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

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

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

स्थैतिक परीक्षण में सॉफ़्टवेयर सत्यापन शामिल होता है, जबकि गतिशील परीक्षण में सॉफ़्टवेयर सत्यापन भी शामिल होता है।

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

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

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

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

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

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

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

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

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

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

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

परीक्षण का यह तरीका सॉफ्टवेयर परीक्षण के सभी स्तरों पर लागू किया जा सकता है: इकाई परीक्षण, एकीकरण परीक्षण, सिस्टम परीक्षण और स्वीकृति परीक्षण। यह आम तौर पर उच्च स्तर पर सभी परीक्षण नहीं होने पर सबसे अधिक शामिल होता है, लेकिन यूनिट परीक्षण पर भी हावी हो सकता है।

घटक इंटरफ़ेस परीक्षण

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

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

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

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

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

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

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

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

यूनिट परीक्षण एक सॉफ्टवेयर विकास प्रक्रिया है जिसमें सॉफ्टवेयर विकास जोखिम, समय और लागत को कम करने के लिए दोष निवारण और पहचान रणनीतियों के व्यापक स्पेक्ट्रम का एक सिंक्रनाइज़ अनुप्रयोग शामिल है। यह सॉफ्टवेयर विकास जीवन चक्र के निर्माण चरण के दौरान सॉफ्टवेयर डेवलपर या इंजीनियर द्वारा किया जाता है। यूनिट परीक्षण का उद्देश्य अतिरिक्त परीक्षण के लिए कोड को बढ़ावा देने से पहले निर्माण त्रुटियों को समाप्त करना है; इस रणनीति का उद्देश्य परिणामी सॉफ़्टवेयर की गुणवत्ता के साथ-साथ समग्र विकास प्रक्रिया की दक्षता में वृद्धि करना है।

सॉफ़्टवेयर विकास के लिए संगठन की अपेक्षाओं के आधार पर, इकाई परीक्षण में स्थिर कोड विश्लेषण, डेटा प्रवाह विश्लेषण, मेट्रिक्स विश्लेषण, सहकर्मी कोड समीक्षा, कोड कवरेज विश्लेषण और अन्य सॉफ़्टवेयर परीक्षण अभ्यास शामिल हो सकते हैं।

एकीकरण परीक्षण
एकीकरण परीक्षण किसी भी प्रकार का सॉफ़्टवेयर परीक्षण है जो सॉफ़्टवेयर डिज़ाइन के विरुद्ध घटकों के बीच इंटरफेस को सत्यापित करने का प्रयास करता है। सॉफ़्टवेयर घटकों को पुनरावृत्त तरीके से या सभी को एक साथ (बिग बैंग) एकीकृत किया जा सकता है। आम तौर पर पूर्व को एक बेहतर अभ्यास माना जाता है क्योंकि यह इंटरफ़ेस के मुद्दों को अधिक तेज़ी से और ठीक करने की अनुमति देता है।

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

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

स्वीकृति परीक्षण
स्वीकृति परीक्षण में आमतौर पर निम्नलिखित चार प्रकार शामिल होते हैं:


 * उपयोगकर्ता स्वीकृति परीक्षण (यूएटी)
 * परिचालन स्वीकृति परीक्षण (OAT)
 * संविदात्मक और नियामक स्वीकृति परीक्षण
 * अल्फा और बीटा परीक्षण

UAT के साथ-साथ अल्फ़ा और बीटा परीक्षण का वर्णन अगले #परीक्षण प्रकार अनुभाग में किया गया है।

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

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

परीक्षण प्रकार, तकनीक और रणनीति
अलग-अलग लेबल और समूहीकरण परीक्षण के तरीके परीक्षण प्रकार, सॉफ़्टवेयर परीक्षण रणनीति या तकनीक हो सकते हैं।



स्थापना परीक्षण
अधिकांश सॉफ़्टवेयर सिस्टम में स्थापना प्रक्रियाएँ होती हैं जिनकी आवश्यकता उनके मुख्य उद्देश्य के लिए उपयोग किए जाने से पहले होती है। एक स्थापित सॉफ़्टवेयर सिस्टम को प्राप्त करने के लिए इन प्रक्रियाओं का परीक्षण करना, जिसका उपयोग किया जा सकता है, स्थापना परीक्षण के रूप में जाना जाता है।

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

धुआँ और विवेक परीक्षण
विवेक परीक्षण यह निर्धारित करता है कि आगे के परीक्षण के साथ आगे बढ़ना उचित है या नहीं।

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

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

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

स्वीकृति परीक्षण
स्वीकृति परीक्षण का अर्थ दो चीजों में से एक हो सकता है:


 * 1) एक धूम्रपान परीक्षण (सॉफ्टवेयर) का उपयोग आगे के परीक्षण से पहले निर्माण स्वीकृति परीक्षण के रूप में किया जाता है, उदाहरण के लिए, एकीकरण परीक्षण या प्रतिगमन परीक्षण से पहले।
 * 2) ग्राहक द्वारा किया गया स्वीकृति परीक्षण, अक्सर उनके स्वयं के हार्डवेयर पर प्रयोगशाला वातावरण में, उपयोगकर्ता स्वीकृति परीक्षण (यूएटी) के रूप में जाना जाता है। विकास के किन्हीं दो चरणों के बीच हैंड-ऑफ़ प्रक्रिया के भाग के रूप में स्वीकृति परीक्षण किया जा सकता है।

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

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

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

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

सतत परीक्षण
निरंतर परीक्षण सॉफ्टवेयर डिलीवरी पाइपलाइन के हिस्से के रूप में परीक्षण स्वचालन को निष्पादित करने की प्रक्रिया है, जो सॉफ़्टवेयर रिलीज़ उम्मीदवार से जुड़े व्यावसायिक जोखिमों पर तत्काल प्रतिक्रिया प्राप्त करने के लिए है। निरंतर परीक्षण में कार्यात्मक आवश्यकताओं और गैर-कार्यात्मक आवश्यकताओं दोनों का सत्यापन शामिल है; परीक्षण का दायरा व्यापक व्यावसायिक लक्ष्यों से जुड़ी सिस्टम आवश्यकताओं का आकलन करने के लिए नीचे-ऊपर की आवश्यकताओं या उपयोगकर्ता कहानियों को मान्य करने तक फैला हुआ है।

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

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

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

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

रीयल-टाइम कंप्यूटिंग | रीयल-टाइम सॉफ़्टवेयर सिस्टम में सख्त समय सीमा होती है। यह जांचने के लिए कि क्या समय की कमी पूरी होती है, रीयल-टाइम परीक्षण का उपयोग किया जाता है।

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

अभिगम्यता परीक्षण
अभिगम्यता परीक्षण यह सुनिश्चित करने के लिए किया जाता है कि सॉफ्टवेयर विकलांग व्यक्तियों के लिए सुलभ है। कुछ सामान्य वेब सरल उपयोग टेस्ट हैं


 * यह सुनिश्चित करना कि फॉन्ट और पृष्ठभूमि के रंग के बीच का रंग कंट्रास्ट उचित है
 * फ़ॉन्ट आकार
 * मल्टीमीडिया सामग्री के लिए वैकल्पिक पाठ
 * माउस के अलावा कंप्यूटर कीबोर्ड का उपयोग करके सिस्टम का उपयोग करने की क्षमता।

अनुपालन के लिए सामान्य मानक
 * अमेरिकी विकलांग अधिनियम 1990
 * धारा 508 पुनर्वास अधिनियम 1973 में संशोधन
 * विश्वव्यापी वेब संकाय (W3C) की वेब अभिगम्यता पहल (WAI)

सुरक्षा परीक्षण
हैकर (कंप्यूटर सुरक्षा) द्वारा पिछले दरवाजे (कंप्यूटिंग) को रोकने के लिए गोपनीय डेटा को संसाधित करने वाले सॉफ़्टवेयर के लिए सुरक्षा परीक्षण आवश्यक है।

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

अंतर्राष्ट्रीयकरण और स्थानीयकरण
अंतर्राष्ट्रीयकरण और स्थानीयकरण के लिए परीक्षण पुष्टि करता है कि सॉफ़्टवेयर का उपयोग विभिन्न भाषाओं और भौगोलिक क्षेत्रों के साथ किया जा सकता है। छद्म स्थानीयकरण की प्रक्रिया का उपयोग किसी एप्लिकेशन की किसी अन्य भाषा में अनुवाद करने की क्षमता का परीक्षण करने के लिए किया जाता है, और यह पहचानना आसान बनाता है कि स्थानीयकरण प्रक्रिया उत्पाद में नए बग कब पेश कर सकती है।

वैश्वीकरण परीक्षण सत्यापित करता है कि सॉफ्टवेयर एक नई संस्कृति (जैसे विभिन्न मुद्राओं या समय क्षेत्रों) के लिए अनुकूलित है। मानव भाषाओं में वास्तविक अनुवाद का भी परीक्षण किया जाना चाहिए। संभावित स्थानीयकरण और वैश्वीकरण विफलताओं में शामिल हैं:


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

विकास परीक्षण
विकास परीक्षण एक सॉफ्टवेयर विकास प्रक्रिया है जिसमें सॉफ्टवेयर विकास जोखिम, समय और लागत को कम करने के लिए दोष निवारण और पहचान रणनीतियों के व्यापक स्पेक्ट्रम के समकालिक अनुप्रयोग शामिल हैं। यह सॉफ्टवेयर विकास जीवनचक्र के निर्माण चरण के दौरान सॉफ्टवेयर डेवलपर या इंजीनियर द्वारा किया जाता है। विकास परीक्षण का उद्देश्य अन्य परीक्षण में कोड को बढ़ावा देने से पहले निर्माण त्रुटियों को खत्म करना है; इस रणनीति का उद्देश्य परिणामी सॉफ़्टवेयर की गुणवत्ता के साथ-साथ समग्र विकास प्रक्रिया की दक्षता में वृद्धि करना है।

सॉफ़्टवेयर विकास के लिए संगठन की अपेक्षाओं के आधार पर, विकास परीक्षण में स्थिर कोड विश्लेषण, डेटा प्रवाह विश्लेषण, मेट्रिक्स विश्लेषण, सहकर्मी कोड समीक्षा, इकाई परीक्षण, कोड कवरेज विश्लेषण, आवश्यकताएँ पता लगाने की क्षमता और अन्य सॉफ़्टवेयर परीक्षण अभ्यास शामिल हो सकते हैं।

ए/बी परीक्षण
A/B टेस्टिंग एक नियंत्रित प्रयोग चलाने की एक विधि है जो यह निर्धारित करती है कि प्रस्तावित परिवर्तन वर्तमान दृष्टिकोण से अधिक प्रभावी है या नहीं। ग्राहकों को सुविधा के वर्तमान संस्करण (नियंत्रण) या संशोधित संस्करण (उपचार) पर भेजा जाता है और यह निर्धारित करने के लिए डेटा एकत्र किया जाता है कि कौन सा संस्करण वांछित परिणाम प्राप्त करने में बेहतर है।

समवर्ती परीक्षण
समवर्ती या समवर्ती परीक्षण सॉफ्टवेयर और सिस्टम के व्यवहार और प्रदर्शन का आकलन करता है जो आम तौर पर सामान्य उपयोग की शर्तों के तहत समवर्ती कंप्यूटिंग का उपयोग करते हैं। इस प्रकार के परीक्षण से सामने आने वाली विशिष्ट समस्याएं गतिरोध, दौड़ की स्थिति और साझा मेमोरी/संसाधन प्रबंधन के साथ समस्याएं हैं।

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

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

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

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

संपत्ति परीक्षण को कभी-कभी उत्पादक परीक्षण या त्वरित जांच चेक परीक्षण के रूप में भी जाना जाता है क्योंकि इसे हास्केल लाइब्रेरी क्विक चेक द्वारा पेश और लोकप्रिय किया गया था।

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

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

इस तकनीक को रूबी लाइब्रेरी vcr द्वारा वेब विकास में लोकप्रिय बनाया गया था।

पारंपरिक जलप्रपात विकास मॉडल
जलप्रपात विकास में एक सामान्य अभ्यास यह है कि परीक्षण परीक्षकों के एक स्वतंत्र समूह द्वारा किया जाता है। ऐसा हो सकता है:

हालाँकि, जलप्रपात विकास मॉडल में भी, यूनिट परीक्षण अक्सर सॉफ्टवेयर डेवलपमेंट टीम द्वारा किया जाता है, तब भी जब एक अलग टीम द्वारा आगे का परीक्षण किया जाता है।
 * कार्यक्षमता विकसित होने के बाद, लेकिन ग्राहक को भेजने से पहले। इस अभ्यास के परिणामस्वरूप अक्सर परीक्षण चरण का उपयोग परियोजना प्रबंधन बफर के रूप में किया जाता है ताकि परियोजना में देरी की भरपाई की जा सके, जिससे परीक्षण के लिए समर्पित समय से समझौता किया जा सके।
 * उसी क्षण विकास परियोजना शुरू होती है, एक सतत प्रक्रिया के रूप में जब तक परियोजना समाप्त नहीं हो जाती।

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

इस परीक्षण प्रक्रिया का अंतिम लक्ष्य निरंतर एकीकरण का समर्थन करना और दोष दर को कम करना है।

यह पद्धति किसी भी औपचारिक परीक्षण दल तक पहुँचने से पहले, विकास द्वारा किए गए परीक्षण प्रयास को बढ़ा देती है। कुछ अन्य विकास मॉडल में, अधिकांश परीक्षण निष्पादन आवश्यकताओं को परिभाषित करने और कोडिंग प्रक्रिया पूरी होने के बाद होता है।

एक नमूना परीक्षण चक्र
हालांकि संगठनों के बीच भिन्नताएं मौजूद हैं, परीक्षण के लिए एक विशिष्ट चक्र है। जलप्रपात विकास मॉडल को नियोजित करने वाले संगठनों के बीच नीचे दिया गया नमूना सामान्य है। अन्य विकास मॉडलों में आमतौर पर समान प्रथाएं पाई जाती हैं, लेकिन यह उतनी स्पष्ट या स्पष्ट नहीं हो सकती हैं।


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

स्वचालित परीक्षण
कई प्रोग्रामिंग समूह ज्यादा से ज्यादा भरोसा कर रहे हैं  परीक्षण स्वचालन पर, विशेष रूप से समूह जो परीक्षण-संचालित विकास का उपयोग करते हैं। कई रूपरेखाएँ हैं  में परीक्षण लिखने के लिए, और निरंतर एकीकरण सॉफ़्टवेयर स्वचालित रूप से परीक्षण चलाएगा हर बार कोड को संस्करण नियंत्रण प्रणाली में चेक किया जाता है।

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

परीक्षण उपकरण
परीक्षण उपकरण और डिबगर्स द्वारा कार्यक्रम परीक्षण और दोष का पता लगाने में महत्वपूर्ण सहायता की जा सकती है। परीक्षण/डीबग टूल में निम्न विशेषताएं शामिल हैं:


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

इनमें से कुछ विशेषताओं को एक समग्र उपकरण या एक एकीकृत विकास पर्यावरण (आईडीई) में शामिल किया जा सकता है।

कैप्चर और रीप्ले
कैप्चर और रीप्ले टेस्टिंग में एप्लिकेशन के साथ इंटरैक्ट करते समय एंड-टू-एंड उपयोग परिदृश्य एकत्र करना और इन परिदृश्यों को परीक्षण मामलों में बदलना शामिल है। कैप्चर और रीप्ले के संभावित अनुप्रयोगों में प्रतिगमन परीक्षणों की पीढ़ी शामिल है। SCARPE उपकरण अध्ययन के तहत आवेदन के एक सबसेट को चुनिंदा रूप से कैप्चर करता है क्योंकि यह निष्पादित होता है। JRapture एक निष्पादित जावा प्रोग्राम और होस्ट सिस्टम पर घटकों जैसे फाइल, या ग्राफिकल यूजर इंटरफेस पर घटनाओं के बीच बातचीत के अनुक्रम को कैप्चर करता है। इन दृश्यों को अवलोकन-आधारित परीक्षण के लिए फिर से चलाया जा सकता है। सायवा एट अल। महत्वपूर्ण सुरक्षा बगों के लिए उम्मीदवार पैच का परीक्षण करने के लिए रिकॉर्ड किए गए उपयोगकर्ता निष्पादन निशान को फिर से चलाने वाले तदर्थ परीक्षण उत्पन्न करने का प्रस्ताव। पंक्ति फोकस्ड डिफरेंशियल यूनिट टेस्ट जेनरेट करने के लिए प्रोडक्शन में ऑब्जेक्ट प्रोफाइल कलेक्ट करती है। यह टूल व्युत्पन्न टेस्ट ऑरेकल की व्यवस्थित पीढ़ी के साथ कैप्चर और रीप्ले को बढ़ाता है। AutographQL, GraphQL API पर उपयोगकर्ता के अनुरोधों की निगरानी करता है और परीक्षण मामलों को उत्पन्न करता है जो स्कीमा दोषों का पता लगा सकते हैं

सॉफ्टवेयर परीक्षण में माप
गुणवत्ता उपायों में शुद्धता (कंप्यूटर विज्ञान), पूर्णता, कंप्यूटर सुरक्षा ऑडिट और ISO/IEC 9126 आवश्यकताएं जैसे क्षमता, विश्वसनीयता इंजीनियरिंग, एल्गोरिथम दक्षता, में porting, रखरखाव, अनुकूलता और उपयोगिता जैसे विषय शामिल हैं।

अक्सर उपयोग किए जाने वाले कई सॉफ़्टवेयर मेट्रिक्स या उपाय हैं, जिनका उपयोग सॉफ़्टवेयर की स्थिति या परीक्षण की पर्याप्तता को निर्धारित करने में सहायता के लिए किया जाता है।

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


 * कक्षा I: एक परिमित पूर्ण परीक्षण सूट मौजूद है।
 * कक्षा II: किसी भी आंशिक विभेदक दर (अर्थात्, सही प्रणालियों को गलत प्रणालियों से अलग करने की कोई अपूर्ण क्षमता) तक सीमित परीक्षण सूट के साथ पहुँचा जा सकता है।
 * कक्षा III: एक गणनीय पूर्ण परीक्षण सूट मौजूद है।
 * चतुर्थ श्रेणी: एक पूर्ण परीक्षण सूट मौजूद है।
 * कक्षा V: सभी मामले।

यह साबित हो गया है कि प्रत्येक वर्ग अगले में सख्ती से शामिल है। उदाहरण के लिए, परीक्षण जब हम मानते हैं कि परीक्षण के तहत कार्यान्वयन के व्यवहार को नियतात्मक परिमित-राज्य मशीन द्वारा निविष्टियों और आउटपुट के कुछ ज्ञात परिमित सेटों के लिए निरूपित किया जा सकता है और कुछ ज्ञात अवस्थाएँ कक्षा I (और सभी बाद की कक्षाओं) से संबंधित हैं ). हालाँकि, यदि राज्यों की संख्या ज्ञात नहीं है, तो यह केवल द्वितीय श्रेणी से सभी वर्गों के अंतर्गत आता है। यदि परीक्षण के तहत कार्यान्वयन एक निर्धारक परिमित-राज्य मशीन होना चाहिए जो एकल ट्रेस (और इसकी निरंतरता) के लिए विनिर्देश को विफल कर दे, और इसकी राज्यों की संख्या अज्ञात है, तो यह केवल कक्षा III से कक्षाओं के अंतर्गत आता है। टेम्पोरल मशीनों का परीक्षण जहां कुछ वास्तविक-बाध्य अंतराल के भीतर इनपुट का उत्पादन किया जाता है, केवल कक्षा IV से संबंधित है, जबकि कई गैर-नियतात्मक प्रणालियों का परीक्षण केवल कक्षा V से संबंधित है (लेकिन सभी नहीं, और कुछ भी कक्षा I से संबंधित हैं) ). कक्षा I में शामिल करने के लिए कल्पित संगणना मॉडल की सरलता की आवश्यकता नहीं है, क्योंकि कुछ परीक्षण मामलों में किसी प्रोग्रामिंग भाषा में लिखे गए कार्यान्वयन शामिल हैं, और निरंतर परिमाण के आधार पर मशीनों के रूप में परिभाषित परीक्षण कार्यान्वयन, कक्षा I में साबित हुए हैं। अन्य विस्तृत मामले, जैसे मैथ्यू हेनेसी द्वारा टेस्टिंग फ्रेमवर्क मस्ट सिमेंटिक्स के तहत, और तर्कसंगत टाइमआउट वाली टेम्पोरल मशीन, क्लास II से संबंधित हैं।

कलाकृतियों का परीक्षण
एक सॉफ्टवेयर परीक्षण प्रक्रिया कई आर्टिफैक्ट (सॉफ्टवेयर विकास) का उत्पादन कर सकती है। उत्पादित वास्तविक कलाकृतियाँ उपयोग किए गए सॉफ़्टवेयर विकास मॉडल, हितधारक और संगठनात्मक आवश्यकताओं का एक कारक हैं।


 * परीक्षण योजना: एक परीक्षण योजना एक दस्तावेज है जो उस दृष्टिकोण का विवरण देता है जो इच्छित परीक्षण गतिविधियों के लिए लिया जाएगा। योजना में उद्देश्य, कार्यक्षेत्र, प्रक्रियाओं और प्रक्रियाओं, कर्मियों की आवश्यकताओं और आकस्मिक योजनाओं जैसे पहलुओं को शामिल किया जा सकता है। परीक्षण योजना एकल योजना के रूप में आ सकती है जिसमें सभी प्रकार के परीक्षण (जैसे स्वीकृति या सिस्टम परीक्षण योजना) और योजना संबंधी विचार शामिल हैं, या इसे मास्टर परीक्षण योजना के रूप में जारी किया जा सकता है जो एक से अधिक विस्तृत परीक्षण का अवलोकन प्रदान करता है योजना (एक योजना की एक योजना)। एक परीक्षण योजना, कुछ मामलों में, एक व्यापक परीक्षण रणनीति का हिस्सा हो सकती है, जो समग्र परीक्षण दृष्टिकोणों का दस्तावेजीकरण करती है, जो स्वयं एक मास्टर परीक्षण योजना या एक अलग आर्टिफैक्ट भी हो सकती है।
 * पता लगाने की क्षमता मैट्रिक्स: एक पता लगाने की क्षमता का मापदंड एक तालिका है जो दस्तावेज़ों का परीक्षण करने के लिए आवश्यकताओं या डिज़ाइन दस्तावेज़ों को सहसंबंधित करती है। आवश्यकता कवरेज पर विचार करके प्रतिगमन परीक्षणों की योजना बनाते समय निष्पादन के लिए परीक्षण मामलों का चयन करने के लिए संबंधित स्रोत दस्तावेज़ों को बदलते समय परीक्षणों को बदलने के लिए इसका उपयोग किया जाता है।
 * परीक्षण का मामला: एक परीक्षण मामले में आम तौर पर एक विशिष्ट पहचानकर्ता, एक डिजाइन विनिर्देश, पूर्व शर्त, घटनाओं, चरणों की एक श्रृंखला (जिसे क्रियाओं के रूप में भी जाना जाता है), इनपुट, आउटपुट, अपेक्षित परिणाम और वास्तविक परिणाम से आवश्यकता संदर्भ होते हैं। चिकित्सकीय रूप से परिभाषित, एक परीक्षण मामला एक इनपुट और एक अपेक्षित परिणाम है। यह 'शर्त x के लिए आपका व्युत्पन्न परिणाम y है' के रूप में संक्षिप्त हो सकता है, हालांकि आम तौर पर परीक्षण के मामले इनपुट परिदृश्य का अधिक विस्तार से वर्णन करते हैं और क्या परिणाम अपेक्षित हो सकते हैं। यह कभी-कभी चरणों की एक श्रृंखला हो सकती है (लेकिन अक्सर चरणों को एक अलग परीक्षण प्रक्रिया में शामिल किया जाता है जिसे अर्थव्यवस्था के मामले में कई परीक्षण मामलों के विरुद्ध प्रयोग किया जा सकता है) लेकिन एक अपेक्षित परिणाम या अपेक्षित परिणाम के साथ। वैकल्पिक फ़ील्ड एक टेस्ट केस आईडी, टेस्ट स्टेप, या निष्पादन संख्या का क्रम, संबंधित आवश्यकताएं, गहराई, टेस्ट श्रेणी, लेखक और चेक बॉक्स हैं कि क्या परीक्षण स्वचालित है और स्वचालित किया गया है। बड़े परीक्षण मामलों में पूर्वापेक्षित अवस्थाएँ या चरण और विवरण भी हो सकते हैं। एक परीक्षण मामले में वास्तविक परिणाम के लिए भी एक स्थान होना चाहिए। इन चरणों को एक वर्ड प्रोसेसर दस्तावेज़, स्प्रेडशीट, डेटाबेस, या अन्य सामान्य रिपॉजिटरी में संग्रहीत किया जा सकता है। एक डेटाबेस सिस्टम में, आप पिछले परीक्षण परिणामों को देखने में भी सक्षम हो सकते हैं, जिन्होंने परिणाम उत्पन्न किए, और उन परिणामों को उत्पन्न करने के लिए किस सिस्टम कॉन्फ़िगरेशन का उपयोग किया गया था। ये पिछले परिणाम आमतौर पर एक अलग तालिका में संग्रहीत किए जाते हैं।
 * टेस्ट स्क्रिप्ट: एक टेस्ट स्क्रिप्ट एक प्रक्रिया या प्रोग्रामिंग कोड है जो उपयोगकर्ता क्रियाओं को दोहराता है। प्रारंभ में, यह शब्द स्वचालित प्रतिगमन परीक्षण उपकरण द्वारा बनाए गए कार्य के उत्पाद से लिया गया था। किसी टूल या प्रोग्राम का उपयोग करके टेस्ट स्क्रिप्ट बनाने के लिए एक टेस्ट केस बेसलाइन होगा।
 * टेस्ट सूट: टेस्ट केस के संग्रह के लिए सबसे आम शब्द टेस्ट सूट है। परीक्षण सूट में अक्सर परीक्षण मामलों के प्रत्येक संग्रह के लिए अधिक विस्तृत निर्देश या लक्ष्य होते हैं। इसमें निश्चित रूप से एक खंड होता है जहां परीक्षक परीक्षण के दौरान उपयोग किए जाने वाले सिस्टम कॉन्फ़िगरेशन की पहचान करता है। परीक्षण मामलों के एक समूह में पूर्वापेक्षित अवस्थाएँ या चरण और निम्नलिखित परीक्षणों का विवरण भी हो सकता है।
 * परीक्षण स्थिरता या परीक्षण डेटा: ज्यादातर मामलों में, किसी विशेष सुविधा की समान कार्यक्षमता का परीक्षण करने के लिए मूल्यों या डेटा के एकाधिक सेट का उपयोग किया जाता है। सभी परीक्षण मूल्यों और परिवर्तनशील पर्यावरणीय घटकों को अलग-अलग फाइलों में एकत्र किया जाता है और परीक्षण डेटा के रूप में संग्रहीत किया जाता है। यह डेटा क्लाइंट को और उत्पाद या प्रोजेक्ट के साथ प्रदान करने के लिए भी उपयोगी है। डेटा उत्पादन का परीक्षण करें जनरेट करने की तकनीकें हैं।
 * दोहन ​​परीक्षण: सॉफ्टवेयर, उपकरण, डेटा इनपुट और आउटपुट के नमूने, और कॉन्फ़िगरेशन सभी को सामूहिक रूप से टेस्ट हार्नेस के रूप में संदर्भित किया जाता है।
 * टेस्ट रन: टेस्ट केस या टेस्ट सूट चलाने से परिणामों की रिपोर्ट

प्रमाणपत्र
सॉफ्टवेयर परीक्षकों और गुणवत्ता आश्वासन विशेषज्ञों की पेशेवर आकांक्षाओं का समर्थन करने के लिए कई प्रमाणन कार्यक्रम मौजूद हैं। ध्यान दें कि कुछ चिकित्सकों का तर्क है कि परीक्षण क्षेत्र प्रमाणन के लिए तैयार नहीं है, जैसा कि #विवाद खंड में उल्लेख किया गया है।

विवाद
कुछ प्रमुख सॉफ्टवेयर परीक्षण विवादों में शामिल हैं:


 * फुर्तीली बनाम पारंपरिक: क्या परीक्षकों को अनिश्चितता और निरंतर परिवर्तन की परिस्थितियों में काम करना सीखना चाहिए या उन्हें क्षमता परिपक्वता मॉडल | प्रक्रिया परिपक्वता का लक्ष्य रखना चाहिए? चुस्त परीक्षण आंदोलन को 2006 से मुख्य रूप से व्यावसायिक हलकों में बढ़ती लोकप्रियता मिली है, जबकि सरकार और सेना सॉफ्टवेयर प्रदाता इस पद्धति का उपयोग करते हैं, लेकिन पारंपरिक परीक्षण-अंतिम मॉडल (जैसे, जलप्रपात मॉडल में) का भी उपयोग करते हैं।
 * मैनुअल बनाम स्वचालित परीक्षण: कुछ लेखकों का मानना ​​है कि परीक्षण स्वचालन इसके मूल्य की तुलना में इतना महंगा है कि इसे कम से कम इस्तेमाल किया जाना चाहिए। परीक्षण स्वचालन को आवश्यकताओं को पकड़ने और कार्यान्वित करने का एक तरीका माना जा सकता है। एक सामान्य नियम के रूप में, सिस्टम जितना बड़ा होगा और जटिलता जितनी अधिक होगी, टेस्ट ऑटोमेशन में आरओआई उतना ही अधिक होगा। साथ ही, एक संगठन के भीतर ज्ञान साझा करने के सही स्तर के साथ कई परियोजनाओं पर उपकरण और विशेषज्ञता में निवेश को परिशोधित किया जा सकता है।
 * क्या ISO/IEC 29119 सॉफ़्टवेयर परीक्षण मानक का अस्तित्व उचित है?: ISO 29119 मानक के संदर्भ में सॉफ़्टवेयर परीक्षण के संदर्भ-संचालित स्कूल के रैंक से महत्वपूर्ण विरोध का गठन किया गया है। सॉफ्टवेयर परीक्षण के लिए अंतर्राष्ट्रीय सोसायटी जैसे व्यावसायिक परीक्षण संघों ने मानक वापस लेने का प्रयास किया है।
 * कुछ चिकित्सक घोषणा करते हैं कि परीक्षण क्षेत्र प्रमाणन के लिए तैयार नहीं है: अब पेश किए जाने वाले किसी प्रमाणन के लिए वास्तव में आवेदक को सॉफ्टवेयर का परीक्षण करने की अपनी क्षमता दिखाने की आवश्यकता नहीं होती है। कोई प्रमाणीकरण ज्ञान के व्यापक रूप से स्वीकृत निकाय पर आधारित नहीं है। प्रमाणन स्वयं किसी व्यक्ति की उत्पादकता, उनके कौशल या व्यावहारिक ज्ञान को माप नहीं सकता है, और एक परीक्षक के रूप में उनकी क्षमता या व्यावसायिकता की गारंटी नहीं दे सकता है।
 * दोषों को ठीक करने के सापेक्ष खर्च दिखाने के लिए अध्ययन: उनके परिचय और पहचान के आधार पर दोषों को ठीक करने के सापेक्ष खर्च को दिखाने के लिए उपयोग किए जाने वाले अध्ययनों की प्रयोज्यता पर विरोधी विचार हैं। उदाहरण के लिए:

 आमतौर पर यह माना जाता है कि जितनी जल्दी कोई दोष पाया जाता है, उसे ठीक करना उतना ही सस्ता होता है। निम्न तालिका दोष के पता लगाने की अवस्था के आधार पर दोष को ठीक करने की लागत को दर्शाती है। उदाहरण के लिए, यदि आवश्यकताओं में कोई समस्या केवल रिलीज़ के बाद पाई जाती है, तो इसे ठीक करने की लागत आवश्यकताओं की समीक्षा द्वारा पहले ही पाए जाने की तुलना में 10–100 गुना अधिक होगी। आधुनिक निरंतर परिनियोजन प्रथाओं और क्लाउड-आधारित सेवाओं के आगमन के साथ, पुन: परिनियोजन और रखरखाव की लागत समय के साथ कम हो सकती है।



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

Boehm TRW डेटा के लिए एक पेपर का हवाला भी नहीं देता है, सिवाय इसके कि जब वह 2010 में मेकिंग सॉफ्टवेयर के लिए लिख रहा था, और वहां उसने 1976 के मूल लेख का हवाला दिया। बोहेम के लिए सही समय पर TRW में एक बड़ा अध्ययन किया गया है, लेकिन उस पेपर में उस तरह का डेटा नहीं है जो Boehm के दावों का समर्थन करेगा।  

सॉफ्टवेयर सत्यापन और सत्यापन
सत्यापन और सत्यापन (सॉफ्टवेयर) के सहयोग से सॉफ्टवेयर परीक्षण का उपयोग किया जाता है:
 * सत्यापन: क्या हमने सॉफ्टवेयर सही बनाया है? (यानी, क्या यह आवश्यकताओं को लागू करता है)।
 * मान्यता: क्या हमने सही सॉफ्टवेयर बनाया है? (यानी, क्या डिलिवरेबल्स ग्राहक को संतुष्ट करते हैं)।

सत्यापन और सत्यापन शब्द आमतौर पर उद्योग में परस्पर विनिमय के लिए उपयोग किए जाते हैं; विरोधाभासी परिभाषाओं के साथ परिभाषित इन दो शब्दों को देखना भी आम है। सॉफ्टवेयर इंजीनियरिंग शब्दावली की IEEE मानक एसोसिएशन शब्दावली के अनुसार:
 * सत्यापन एक प्रणाली या घटक के मूल्यांकन की प्रक्रिया है जो यह निर्धारित करती है कि किसी दिए गए विकास चरण के उत्पाद उस चरण की शुरुआत में लगाए गए शर्तों को पूरा करते हैं या नहीं।
 * सत्यापन विकास प्रक्रिया के दौरान या उसके अंत में एक प्रणाली या घटक का मूल्यांकन करने की प्रक्रिया है, यह निर्धारित करने के लिए कि क्या यह निर्दिष्ट आवश्यकताओं को पूरा करता है।

और, ISO 9000 मानक के अनुसार:


 * सत्यापन परीक्षा द्वारा और वस्तुनिष्ठ साक्ष्य के प्रावधान के माध्यम से पुष्टि है कि निर्दिष्ट आवश्यकताओं को पूरा किया गया है।
 * सत्यापन परीक्षा द्वारा और वस्तुनिष्ठ साक्ष्य के प्रावधान के माध्यम से पुष्टि है कि एक विशिष्ट इच्छित उपयोग या आवेदन के लिए आवश्यकताओं को पूरा किया गया है।

विरोधाभास आवश्यकताओं और निर्दिष्ट आवश्यकताओं की अवधारणाओं के उपयोग के कारण होता है लेकिन विभिन्न अर्थों के साथ।

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

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

इसलिए, जब इन शब्दों को सामान्य शब्दों में परिभाषित किया जाता है, तो स्पष्ट विरोधाभास गायब हो जाता है।

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

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

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

इस पेज में लापता आंतरिक लिंक की सूची

 * परीक्षण ओरेकल
 * दोष (प्रौद्योगिकी)
 * सोर्स कोड
 * मानव त्रुटि
 * कंप्यूटर का प्रदर्शन
 * रख-रखाव
 * प्रयोज्य
 * अनिच्छुक अनुकूलता
 * स्थिरता अभियांत्रिकी)
 * सॉफ्टवेयर पूर्वाभ्यास
 * सॉफ्टवेयर निरीक्षण
 * को़ड समीक्षा
 * परीक्षण मामला
 * समारोह (कंप्यूटर विज्ञान)
 * स्थैतिक कार्यक्रम विश्लेषण
 * विधि ठूंठ
 * सॉफ्टवेयर सत्यापन
 * सॉफ्टवेयर सत्यापन
 * सं कनेर
 * खोजपूर्ण परीक्षण
 * समारोह अंक
 * बहाव को काबू करें
 * समान विभाजन
 * मॉडल आधारित परीक्षण
 * उदाहरण
 * क्रियात्मक परीक्षण
 * अध्याय परीक्षा
 * स्वीकरण परीक्षा
 * एक्सेप्शन हेंडलिंग
 * कोने का मामला
 * सॉफ्टवेयर की रखरखाव
 * गुणवत्ता संचालकीय प्रणाली
 * सॉफ्टवेयर डेवलपमेंट
 * सॉफ्टवेयर परीक्षण रणनीति
 * मतिहीनता (कंप्यूटर विज्ञान)
 * सॉफ्टवेयर वर्जनिंग
 * कंप्यूटर अनुकूलता
 * सत्यापन परीक्षण बनाएँ
 * धुआँ परीक्षण (सॉफ्टवेयर)
 * सॉफ्टवेयर प्रतिगमन
 * सदा बीटा
 * बाधा (गणित)
 * कार्यकारी आवश्यकताएं
 * वास्तविक समय परीक्षण
 * 1990 के अमेरिकी विकलांग अधिनियम
 * 1973 के पुनर्वास अधिनियम में धारा 508 संशोधन
 * पर्यावरणपरिवर्ती तारक
 * सीजेके वर्ण
 * देश द्वारा दिनांक और समय अंकन
 * अक्षरों को सांकेतिक अक्षरों में बदलना
 * परीक्षण संचालित विकास
 * लगातार एकीकरण
 * टेस्ट परिदृश्य
 * आवश्यकताओं के विश्लेषण
 * ब्रेकपाइंट
 * रूपरेखा (कंप्यूटर प्रोग्रामिंग)
 * हॉट स्पॉट (कंप्यूटर साइंस)
 * कार्यक्रम एनिमेशन
 * स्थिरता अभियांत्रिकी
 * परिमित अवस्था मशीन
 * विरूपण साक्ष्य (सॉफ्टवेयर विकास)
 * झरना मॉडल
 * निरंतर तैनाती
 * IEEE मानक संघ
 * सॉफ्टवेयर क्वालिटी एश्योरेंस

बाहरी कड़ियाँ

 * "Software that makes Software better" Economist.com
 * "Software that makes Software better" Economist.com