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

सॉफ्टवेयर परीक्षण एक अनुभवजन्य खोज है, जिसके तहत हितधारकों को परीक्षणाधीन उत्पाद या सेवा की गुणवत्ता^[1] के बारे में, उस संदर्भ में जानकारी उपलब्ध कराई जाती है, जहाँ इसे प्रयोग के लिए नियत किया गया है। सॉफ्टवेयर परीक्षण, उद्योग को सॉफ्टवेयर के कार्यान्वयन में जोखिम को समझने और सराहना करने की अनुमति देने के लिए, सॉफ्टवेयर का उद्देश्य और स्वतंत्र अवलोकन भी प्रदान करता है। टेस्ट तकनीकों में शामिल है, लेकिन इतने तक ही सीमित नहीं, सॉफ्टवेयर बग खोजने के इरादे से एक प्रोग्राम या अनुप्रयोग के निष्पादन की प्रक्रिया।

यह भी कहा जा सकता है कि सॉफ्टवेयर परीक्षण वह प्रक्रिया है, जो यह विधिमान्य और सत्यापित करती है कि एक सॉफ्टवेयर प्रोग्राम/अनुप्रयोग/उत्पाद:

उन व्यावसायिक और तकनीकी आवश्यकताओं को पूरा करता है, जिसने इसके डिज़ाइन और विकास को प्रेरित किया;
आशा के अनुरूप काम करता है और
उन्ही विशेषताओं के साथ लागू किया जा सकता है।

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

सिंहावलोकन

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

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

2002 में NIST द्वारा किए गए एक अध्ययन से यह पता चलता है कि सॉफ्टवेयर बग से अमेरिकी अर्थव्यवस्था को सालाना $59.5 बीलियन की चपत लगती है। यदि बेहतर सॉफ्टवेयर परीक्षण की जाए, तो इस लागत का एक तिहाई हिस्सा बचाया जा सकता है।^[3]

इतिहास

प्रारंभ में परीक्षण से डीबगिंग के पृथक्करण को ग्लेन्फोर्ड जे. मायर्स द्वारा 1979 में प्रवर्तित किया गया। ^[4] हालांकि उनका ध्यान ब्रेकेज परीक्षण पर था ("एक सफल परीक्षण वह है, जो एक बग को खोजती है"^[4]^[5]) इसने सॉफ्टवेयर इंजीनियरिंग समुदाय की बुनियादी विकास गतिविधियों, जैसे डीबगिंग को सत्यापन से अलग करने की इच्छा की पुष्टि की। डेव गेल्परिन और विलियम सी. हेत्ज़ेल ने 1988 में सॉफ्टवेयर परीक्षण में प्रावस्थाओं और लक्ष्यों को निम्नलिखित चरणों में वर्गीकृत किया है:^[6]

1956 तक - डीबगिंग उन्मुख^[7]
1957-1978 - निरूपण उन्मुख^[8]
1979-1982 - विनाश उन्मुख^[9]
1983-1987 - मूल्यांकन उन्मुख^[10]
1988-2000 - निवारण उन्मुख^[11]

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

कार्यक्षेत्र

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

कार्यात्मक बनाम ग़ैर-कार्यात्मक परीक्षण

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

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

त्रुटियाँ और असफलताएं

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

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

शीघ्र ग़लतियाँ खोजना

आम तौर पर यह माना जाता है कि एक ख़राबी को जितना पहले खोजा जाए, उसे ठीक करना उतना ही सस्ता होता है।^[16] निम्नलिखित तालिका, ख़राबी के पता लगाए जाने वाले चरण के आधार पर, उसे ठीक करने की लागत को दर्शाती है।^[17] उदाहरण के लिए, यदि अपेक्षाओं में कोई समस्या सिर्फ रिलीज़ के बाद सामने आती है, तो इसका खर्चा अपेक्षाओं की समीक्षा द्वारा ही पता लगा लिए जाने के खर्चे से 10-100 गुणा अधिक होगा।

Time Detected					--	Requirements	Architecture	Construction	System Test	Post-Release	--	Time Introduced	Requirements	1×	3×	5–10×	10×	10–100×	--	Architecture	-	1×	10×	15×	25–100×	--	Construction	-	-	1×	10×	10–25×

संगतता

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

इसे एक "सुरक्षा उन्मुख रणनीति" मान सकते हैं, जो कि डेव गेल्परिन और विलियम सी. हेत्ज़ेल द्वारा सुझाए नवीनतम परिक्षण चरण के साथ सटीक बैठता है, जैसा कि नीचे उद्धृत है।^[11].

इनपुट कॉम्बिनेशन और प्री-कंडीशन

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

स्टैटिक बनाम डाइनेमिक परीक्षण

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

सॉफ्टवेयर सत्यापन और प्रमाणीकरण

सॉफ्टवेयर परीक्षण का प्रयोग सत्यापन और प्रमाणीकरण के साहचर्य से किया जाता है:^[19]

सत्यापन: क्या हमने सॉफ्टवेयर को सही बनाया? (यानी, क्या यह विनिर्देशों से मेल खाता है)।
प्रमाणीकरण: क्या हमने सही सॉफ्टवेयर बनाया? (यानी, क्या यह वैसा ही है जैसा ग्राहक चाहता है)।

सत्यापन और प्रमाणीकरण शब्द का आम तौर पर प्रयोग, उद्योग में अन्तर-परिवर्तनशीलता से किया जाता है; इन दोनों शब्दों को ग़लत तरीके से परिभाषित करना भी आम है। IEEE सॉफ्टवेयर इंजीनियरिंग की मानक शब्दावली के अनुसार:

सत्यापन, यह जानने के लिए एक सिस्टम या घटक के मूल्यांकन की प्रक्रिया है कि दिए गए विकास चरण के उत्पाद, चरण के आरंभ में निर्धारित शर्तों को पूरा करते हैं या नहीं।

प्रमाणीकरण विकास की प्रक्रिया के दौरान या अन्त में यह निर्धारित करने के लिए सिस्टम या घटक के मूल्यांकन की प्रक्रिया है कि क्या यह निर्दिष्ट आवश्यकताओं को पूरा करता है।

सॉफ्टवेयर परीक्षण दल

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

सॉफ्टवेयर गुणवत्ता आश्वासन (SQA)

हालांकि विवादास्पद, सॉफ्टवेयर परीक्षण को सॉफ्टवेयर गुणवत्ता आश्वासन (SQA) प्रक्रिया के एक महत्वपूर्ण हिस्से के रूप में देखा जा सकता है।^[12] SQA में, सॉफ्टवेयर प्रक्रिया विशेषज्ञ और लेखा परीक्षक, सॉफ्टवेयर और उसके विकास पर एक व्यापक दृष्टिकोण रखते हैं। वे सॉफ्टवेयर इंजीनियरिंग प्रक्रिया की जांच करते हैं और प्रदत्त सॉफ्टवेयर में मौजूद दोषों: तथाकथित दोष दर की मात्रा को कम करने के लिए उसे ही बदल देते हैं।

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

यद्यपि SQA के साथ घनिष्ठ संबन्ध हैं, परीक्षण विभाग अक्सर स्वतंत्र रूप से कार्य करते हैं और हो सकता है कि किसी कंपनी में SQA का कोई कार्य ना हो।

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

परीक्षण तरीक़े

बॉक्स दृष्टिकोण

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

ब्लैक बॉक्स परीक्षण

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

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

विनिर्देशन आधारित परीक्षण जरूरी है, लेकिन यह कुछ जोखिमों से बचाव करने के लिए अपर्याप्त है।^[21]

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

इसलिए, ब्लैक बॉक्स परीक्षण में एक ओर "एक असम्बद्ध राय" का फायदा है और दूसरी ओर "अंधी तलाश" का नुक्सान। ^[22]

व्हाइट बॉक्स परीक्षण

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

व्हाइट बॉक्स परीक्षण के प्रकार

व्हाइट बॉक्स परीक्षण के निम्नलिखित प्रकार पाए जाते हैं:

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

टेस्ट कवरेज

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

कोड कवरेज के दो आम प्रकार हैं:

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

वे दोनों एक कोड कवरेज मीट्रिक को लौटाते हैं, जिसे प्रतिशत के रूप में मापा जाता है।

ग्रे बॉक्स परीक्षण

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

परीक्षण स्तर

परीक्षणों को अक्सर, सॉफ्टवेयर विकास प्रक्रिया में उनके शामिल होने की जगह के आधार पर वर्गीकृत किया जाता है, या परीक्षण की विशिष्टता के स्तर द्वारा।

यूनिट परीक्षण

यूनिट परीक्षण उन परीक्षणों को संदर्भित करता है, जो कोड के एक विशेष खंड की कार्यशीलता, आम तौर पर प्रक्रिया स्तर पर, सत्यापित करते हैं। एक ऑब्जेक्ट-उन्मुख परिवेश में, यह अक्सर श्रेणी स्तर पर होता है और न्यूनतम इकाई परीक्षण में शामिल होता है कंस्ट्रक्टर और डिस्ट्रक्टर।^[24]

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

इंटीग्रेशन परीक्षण

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

इंटीग्रेशन परीक्षण, इंटरफेस में त्रुटियाँ उजागर करने और एकीकृत घटक (मॉड्यूल) के बीच पारस्परिक क्रिया को दर्शाने के लिए काम करता है। उत्तरोत्तर, आर्कीटेक्चरल डिजाइन के तत्वों के अनुरूप जांचे गए सॉफ्टवेयर घटकों के बड़े समूहों को एकीकृत और तब तक जांचा जाता है, जब तक सॉफ्टवेयर एक सिस्टम के रूप में काम ना करने लगे।^[25]

सिस्टम परीक्षण

सिस्टम परीक्षण यह सत्यापित करने के लिए एक पूरी तरह से एकीकृत सिस्टम का परीक्षण करता है कि वह अपनी आवश्यकताओं को पूरा करता है।^[26]

सिस्टम इंटीग्रेशन परीक्षण

सिस्टम इंटीग्रेशन परीक्षण यह पुष्टि करता है कि एक सिस्टम, सिस्टम आवश्यकताओं में परिभाषित किसी भी बाहरी या अन्य पक्ष के सिस्टम से एकीकृत है। ^[]

रिग्रेशन परीक्षण

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

एक्सेपटेंस परीक्षण

एक्सेपटेंस परीक्षण का तात्पर्य दो में से एक से हो सकता है:

स्मोक टेस्ट को मुख्य परीक्षण प्रक्रिया के लिए, यानी इंटीग्रेशन या रिग्रेशन से पहले, एक नए निर्माण को पेश करने से पहले एक स्वीकृति परीक्षण के रूप में प्रयोग किया जाता है।
ग्राहक द्वारा निष्पादित एक्सेपटेंस परीक्षण, अक्सर उनके प्रयोगशाला परिवेश में उनके खुद के HW पर, को यूज़र एक्सेप्टेंस परीक्षण (UAT) (उपयोगकर्ता स्वीकृति परीक्षण) के रूप में जाना जाता है। एक्सेपटेंस परीक्षण को विकास के किसी भी दो चरणों के बीच, हैण्ड-ऑफ प्रक्रिया के हिस्से के रूप में किया जा सकता है। ^[]

अल्फा परीक्षण

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

बीटा परीक्षण

बीटा परीक्षण अल्फा परीक्षण के बाद आता है। बीटा संस्करण के नाम से विख्यात सॉफ्टवेयर का संस्करण, प्रोग्रामिंग टीम से बाहर एक सीमित ग्राहकों के लिए जारी किया गया। सॉफ्टवेयर को लोगों के समूहों के लिए जारी किया जाता है, ताकि आगे के परीक्षण यह सुनिश्चित कर सकें कि उत्पाद में न्यूनतम खराबियाँ या बग हैं। कभी-कभी, बीटा संस्करण को भावी उपयोगकर्ताओं की अधिकतम संख्या को प्रतिक्रिया के क्षेत्र को बढाने के लिए, खुली जनता के लिए उपलब्ध कराया जाता है। ^[]

ग़ैर कार्यात्मक परीक्षण

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

सॉफ्टवेयर परफोर्मेंस परीक्षण|परफोर्मेंस परीक्षण, या लोड परीक्षण

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

स्टेबिलिटी परीक्षण

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

युसेबिलिटी परीक्षण

प्रयोज्यता परीक्षण की जरूरत यह जांचने के लिए होती है कि यूज़र इंटरफ़ेस का उपयोग करना और उसे समझना आसान है या नहीं।

सिक्योरिटी परीक्षण

सुरक्षा परीक्षण उस सॉफ्टवेयर के लिए जरूरी है जो हैकर्स द्वारा सिस्टम घुसपैठ को रोकने के लिए गोपनीय डाटा को परिष्कृत करता है।

अन्तर्राष्ट्रीयकरण और स्थानीयकरण

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

डिसट्रकटिव परीक्षण

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

परीक्षण प्रक्रिया

पारंपरिक CMMI या वॉटरफ़ॉल विकास मॉडल

सॉफ्टवेयर परीक्षण के एक आम तरीके को, इसे ग्राहक को भेजे जाने से पहले और इसकी कार्यक्षमता विकसित किये जाने के बाद, परीक्षकों के एक स्वतंत्र समूह द्वारा सम्पादित किया जाता है।^[27] इस अभ्यास के परिणामस्वरूप अक्सर परीक्षण चरण का, परियोजना में हुई देरी की क्षतिपूर्ति के लिए परियोजना बफर के रूप में उपयोग किया जाता है और इस प्रकार से परीक्षण के लिए समर्पित समय के साथ समझौता होता है।^[28] एक और परिपाटी है परियोजना के शुरू होने के क्षण ही सॉफ्टवेयर परीक्षण को शुरू कर देना और परियोजना के समापन तक यह एक सतत प्रक्रिया है।^[29]

फुर्तीला या तीव्र विकास मॉडल

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

एक परीक्षण चक्र नमूना

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

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

स्वचालित परीक्षण

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

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

परीक्षण उपकरण

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

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

इन गुणों में से कुछ को एक एकीकृत विकास परिवेश (IDE) में शामिल किया जा सकता है।

सॉफ्टवेयर परीक्षण मापन

आम तौर पर, जिन विषयों तक गुणवत्ता सीमित होती है, वे हैं शुद्धता, संपूर्णता, सुरक्षा,^[] लेकिन ISO मानक ISO 9126 के तहत वर्णित अधिक तकनीकी आवश्यकताएं भी शामिल हो सकती हैं, जैसे क्षमता, विश्वसनीयता, दक्षता, सुवाह्यता, रख-रखाव, संगतता और 0}प्रयोज्यता।

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

आर्टीफैक्ट्स परीक्षण

सॉफ्टवेयर परीक्षण प्रक्रिया कई आर्टीफैक्ट को उत्पन्न कर सकती है।

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

ट्रेसेबिलिटी मैट्रिक्स: एक ट्रेसेबिलिटी मैट्रिक्स एक ऐसी तालिका है, जो अपेक्षाओं या डिजाइन दस्तावेजों को परीक्षण दस्तावेजों से संबद्ध करता है। इसका प्रयोग जब स्रोत दस्तावेज़ बदल रहे हों, तब परीक्षण को बदलने के लिए किया जाता है, या इसकी पुष्टि करने के लिए कि परीक्षण परिणाम सही हैं।

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

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

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

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

टेस्ट हार्नेस: सॉफ्टवेयर, उपकरण, डाटा के इनपुट और आउटपुट नमूने और विन्यास, सभी को सामूहिक रूप से एक टेस्ट हार्नेस के रूप में संदर्भित किया जाता है।

प्रमाणन

सॉफ्टवेयर परीक्षकों और गुणवत्ता आश्वासन विशेषज्ञों की पेशेवर आकांक्षाओं को बल देने के लिए कई प्रमाणन कार्यक्रम मौजूद हैं। वर्तमान में प्रदान किये जाने वाले प्रमाणन में ऐसा कोई नहीं है, जिसमें वास्तव में आवेदक के लिए सॉफ्टवेयर परीक्षण की क्षमता को प्रदर्शित करने की आवश्यकता होती है। कोई भी प्रमाणीकरण, व्यापक रूप से स्वीकृत ज्ञान के ढांचे पर आधारित नहीं है। इस तथ्य ने कुछ लोगों को यह कहने के लिए प्रेरित किया कि परीक्षण क्षेत्र अभी प्रमाणन के लिए तैयार नहीं है।^[32] अकेले प्रमाणन एक व्यक्ति की उत्पादकता, उनके कौशल, या व्यावहारिक ज्ञान को माप नहीं सकता और एक परीक्षक के रूप में उनकी क्षमता, या पेशेवराना शैली की गारंटी नहीं दे सकता.^[33]

सॉफ्टवेयर परीक्षण प्रमाणीकरण प्रकार

परीक्षा आधारित : औपचारिक परीक्षा, जिसे उत्तीर्ण करना ज़रूरी है; स्वाध्याय से भी सीखा जा सकता है,[उदाहरण, ISTQB या QAI के लिए]^[34]
शिक्षा आधारित : प्रशिक्षक के नेतृत्व में सत्र, जहाँ प्रत्येक कोर्स को उत्तीर्ण करना ज़रूरी है [जैसे, इंटरनेशनल इंस्टीट्यूट ऑफ़ सॉफ्टवेयर परीक्षण (IIST)].

परीक्षण प्रमाणन

सर्टिफाइड एसोसिएट इन सॉफ्टवेयर परीक्षण (CAST), क्वालिटी अश्योरेन्स इंस्टीट्यूट (QAI) द्वारा प्रदत्त^[35]
CATe इंटरनेशनल इंस्टीट्यूट ऑफ़ सॉफ्टवेयर परीक्षण^[36] द्वारा प्रदत्त
सर्टिफाइड मैनेजर इन सॉफ्टवेयर परीक्षण (CMST) क्वालिटी अश्योरेन्स इंस्टीट्यूट (QAI) द्वारा प्रदत्त^[35]
सर्टिफाइड सॉफ्टवेयर परीक्षण (CSTE) क्वालिटी अश्योरेन्स इंस्टीट्यूट (QAI) द्वारा प्रदत्त^[35]
सर्टिफाइड सॉफ्टवेयर टेस्ट प्रोफेशनल (CSTP) इंटरनेशनल इंस्टीट्यूट ऑफ़ सॉफ्टवेयर परीक्षण द्वारा प्रदत्त^[36]
CSTP (TM) (ऑस्ट्रेलियाई संस्करण), के.जे. रॉस एंड एसोसिएट्स द्वारा प्रदत्त^[37]
ISEB इन्फ़र्मेशन सिस्टम्स इक्ज़ैमिनेशन बोर्ड द्वारा प्रदत्त
ISTQB सर्टिफाइड टेस्टर, फाउंडेशन लेवल (CTFL) इंटरनेशनल सॉफ्टवेयर परीक्षण क्वालिफिकेशन बोर्ड^[38]^[39] द्वारा प्रदत्त
ISTQB, सर्टिफाइड टेस्टर, एडवांस्ड लेवल (CTAL) इंटरनेशनल सॉफ्टवेयर परीक्षण क्वालिफिकेशन बोर्ड^[38]^[39] द्वारा प्रदत्त
TMPF TMap^{[संदिग्ध – वार्ता]} नेक्स्ट फाउंडेशन इक्ज़ैमिनेशन इंस्टीट्यूट फॉर इन्फर्मेशन साइंस द्वारा प्रदत्त^[40]

गुणवत्ता आश्वासन प्रमाणन

CMSQ क्वालिटी अश्योरेन्स इंस्टीट्यूट (QAI)^[35] द्वारा प्रदत्त
CSQA क्वालिटी अश्योरेन्स इंस्टीट्यूट (QAI) द्वारा प्रदत्त^[35]
CSQE अमेरिकन सोसायटी फॉर क्वालिटी (ASQ) द्वारा प्रदत्त^[41]
CQIA अमेरिकन सोसायटी फॉर क्वालिटी (ASQ) द्वारा प्रदत्त^[41]

विवाद

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

जिम्मेदार सॉफ्टवेयर परीक्षण का गठन किससे होता है?: "कांटेक्स्ट-ड्रिवेन" परीक्षण स्कूल^[42] के सदस्यों का मानना है कि परीक्षण की कोई "सर्वोत्तम प्रथा" नहीं है, उसके बजाय परीक्षण, कौशल का एक सेट है जो परीक्षक को प्रत्येक अनोखी परिस्थिति से मेल खाती परीक्षण प्रथाओं के आविष्कार की अनुमति देता है।^[43]

फुर्तीला बनाम पारंपरिक: क्या परीक्षकों को अनिश्चितता और निरंतर परिवर्तन की स्थितियों के तहत काम करना सीखना चाहिए या उनका लक्ष्य प्रक्रिया "परिपक्वता" पर होना चाहिए? एजाइल परीक्षण आंदोलन को मुख्य रूप से व्यापारिक हलकों में 2006 के बाद से काफी लोकप्रियता मिली^[44]^[45], जबकि सरकारी और सैन्य सॉफ्टवेयर प्रदाता इस पद्धति को अपनाने में धीमे हैं^{[neutralityis disputed]} और अधिकतर अभी भी CMMI से बन्धे हैं।^[46]

Exploratory test vs. scripted^[47]: क्या परीक्षण को उसी समय डिजाइन करना चाहिए, जब उन्हें निष्पादित किया जाता है या उन्हें पहले से तैयार किया जाना चाहिए?

मैनुअल परीक्षण बनाम ऑटोमेटेड: कुछ लेखकों का मानना है कि स्वचालन परीक्षा अपने मूल्य की तुलना में इतना महंगा है कि इसका प्रयोग किफ़ायती तौर पर किया जाना चाहिए.^[48] अन्य, जैसे फुर्तीले विकास की पैरवी करने वाले, सभी परीक्षणों को 100% स्वचालित करने की सलाह देते हैं। ^[] विशेषतः अधिक रूप से, परीक्षण-संचालित विकास का कहना है कि डेवलपर को प्रक्रियाओं की कोडिंग करने से पहले XUnit प्रकार के यूनिट टेस्ट को लिख लेना चाहिए. तब उस टेस्ट को अपेक्षाएं लागू करने और कैप्चर करने के माध्यम के रूप में माना जा सकता है।

Software design vs. software implementation^[49]: क्या परीक्षण को सिर्फ अन्त में करना चाहिए या पूरी प्रक्रिया के दौरान करना चाहिए?

चौकीदार की चौकीदारी कौन करता है? //हु वॉचेस द वॉचमेन?: विचार यह है कि, निरीक्षण का कोई भी रूप एक पारस्परिक क्रिया है - परीक्षण का कार्य उसे भी प्रभावित कर सकता है, जिसका परीक्षण किया जा रहा है।^[50]

इन्हें भी देखें

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

	Book: Software testing
are collections of articles that can be downloaded or ordered in print.

सन्दर्भ

↑ Exploratory Testing Archived 2009-01-26 at the वेबैक मशीन सेम केनर, फ्लॉरिडा प्रौद्योगिकी संस्थान, क्वालिटी अश्योरेन्स इंस्टीट्यूट वर्ल्डवाइड सॉफ्टवेयर परीक्षण कॉन्फरेंस ऑरलैंडो, FL, नवम्बर, 2006
↑ लेटनर, ए, सिउपा, I, ओरिअल, एम, मेयेर, बी, फिवा, ए, "Contract Driven Development = Test Driven Development - Writing Test Cases" Archived 2017-06-30 at the वेबैक मशीन ESEC/FSE07 की कार्यवाही: सॉफ्टवेयर इंजीनियरिंग के आधार पर यूरोपीय सॉफ्टवेयर इंजीनियरिंग सम्मेलन और ACM SIGSOFT संगोष्ठी, 2007, (डबरोवनिक, क्रोएशिया), सितम्बर, 2007
↑ Software errors cost U.S. economy $59.5 billion annually Archived 2013-01-22 at the वेबैक मशीन NIST रिपोर्ट
↑ ^अ ^आ Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. आई॰ऍस॰बी॰ऍन॰ 0-471-04328-1. मूल से 18 सितंबर 2019 को पुरालेखित. अभिगमन तिथि 23 अक्तूबर 2019.
↑ Dr. Dobb's journal of software tools for the professional programmer. M&T Pub. 12 (1–6): 116. 1987 "a+successful+test+is+one+that+finds+a+bug&dq="a+successful+test+is+one+that+finds+a+bug&ei=U44OSsOxBpKSzgSxo4mXAg&pgis=1 http://books.google.com/books?id=7RoIAAAAIAAJ&q="a+successful+test+is+one+that+finds+a+bug&dq="a+successful+test+is+one+that+finds+a+bug&ei=U44OSsOxBpKSzgSxo4mXAg&pgis=1. गायब अथवा खाली |title= (मदद)
↑ Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)
↑ 1956 तक यह डीबगिंग उन्मुख अवधि थी, जब परीक्षण को अक्सर डीबगिंग से संबद्ध किया गया था: डीबगिंग और परीक्षण के बीच कोई स्पष्ट अन्तर मौजूद नहीं था। Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)
↑ 1957-1978 तक, प्रदर्शन उन्मुख अवधि थी, जहाँ डीबगिंग और परीक्षण अब प्रतिष्ठित थे - इस अवधि में यह दिखा कि सॉफ्टवेयर आवश्यकताओं को संतुष्ट करता है। Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)
↑ 1979-1982 के बीच के समय को विनाश उन्मुख अवधि कहा गया, जहाँ लक्ष्य त्रुटि खोजने का था। Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)
↑ 1983-1987 का वर्गीकरण मूल्यांकन उन्मुख अवधि के रूप में किया गया है: उद्देश्य यह है कि सॉफ्टवेयर के जीवन चक्र के दौरान उत्पाद मूल्यांकन और मापन गुणवत्ता प्रदान की जाती है। Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)
↑ ^अ ^आ 1988 से इसे सुरक्षा उन्मुख अवधि के रूप में देखा गया, जहाँ परीक्षण यह दिखाते थे कि सॉफ्टवेयर अपने विनिर्देशन को संतुष्ट करता है, दोष का पता लगाना और दोष को रोकना। Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)
↑ ^अ ^आ ^इ Kaner, Cem (1999). Testing Computer Software, 2nd Ed. New York, et al: John Wiley and Sons, Inc. पपृ॰ 480 pages. आई॰ऍस॰बी॰ऍन॰ 0-471-35846-0. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद) सन्दर्भ त्रुटि: <ref> अमान्य टैग है; "Kaner1" नाम कई बार विभिन्न सामग्रियों में परिभाषित हो चुका है
↑ Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. पृ॰ 41-43. आई॰ऍस॰बी॰ऍन॰ 0470042125. मूल से 25 अप्रैल 2012 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद); |pages= और |page= के एक से अधिक मान दिए गए हैं (मदद)
↑ Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. पृ॰ 86. आई॰ऍस॰बी॰ऍन॰ 0470042125. मूल से 25 अप्रैल 2012 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद); |pages= और |page= के एक से अधिक मान दिए गए हैं (मदद)
↑ ^अ ^आ धारा 1.1.2, Certified Tester Foundation Level Syllabus Archived 2008-12-17 at the वेबैक मशीन इंटरनेशनल सॉफ्टवेयर परीक्षण योग्यता बोर्ड
↑ Kaner, Cem (2001). Lessons Learned in Software Testing: A Context-Driven Approach. Wiley. पृ॰ 4. आई॰ऍस॰बी॰ऍन॰ 0-471-08112-4. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)
↑ McConnell, Steve (2004). Code Complete (2nd संस्करण). Microsoft Press. पपृ॰ 960. आई॰ऍस॰बी॰ऍन॰ 0-7356-1967-0.
↑ सिद्धांत 2, धारा 1.3, Certified Tester Foundation Level Syllabus Archived 2008-12-17 at the वेबैक मशीन अन्तर्राष्ट्रीय सॉफ्टवेयर परीक्षण योग्यता बोर्ड
↑ Tran, Eushiuan (1999). "Verification/Validation/Certification". प्रकाशित Koopman, P. (संपा॰). Topics in Dependable Embedded Systems. USA: Carnegie Mellon University. अभिगमन तिथि 2008-01-13.
↑ Laycock, G. T.. "The Theory and Practice of Specification Based Software Testing" (PostScript). Dept of Computer Science, Sheffield University, UK. अभिगमन तिथि: Archived 2007-02-14 at the वेबैक मशीन "संग्रहीत प्रति". मूल से 14 फ़रवरी 2007 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.
↑ Bach, James (1999). "Risk and Requirements-Based Testing" (PDF). Computer. 32 (6): 113–114. मूल (PDF) से 29 दिसंबर 2009 को पुरालेखित. अभिगमन तिथि 2008-08-19. नामालूम प्राचल |month= की उपेक्षा की गयी (मदद)
↑ Savenkov, Roman (2008). How to Become a Software Tester. Roman Savenkov Consulting. पृ॰ 168. आई॰ऍस॰बी॰ऍन॰ 978-0-615-23372-7.
↑ Introduction Archived 2009-12-27 at the वेबैक मशीन कोड कवरेज विश्लेषण, स्टीव कार्नेट
↑ Binder, Robert V. (1999). Testing Object-Oriented Systems: Objects, Patterns, and Tools. Addison-Wesley Professional. पृ॰ 45. आई॰ऍस॰बी॰ऍन॰ 0-201-80938-9.
↑ Beizer, Boris (1990). Software Testing Techniques (Second संस्करण). New York: Van Nostrand Reinhold. पपृ॰ 21, 430. आई॰ऍस॰बी॰ऍन॰ 0-442-20672-0.
↑ IEEE (1990). IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York: IEEE. आई॰ऍस॰बी॰ऍन॰ 1559370793.
↑ "e)Testing Phase in Software Testing:-". मूल से 24 जुलाई 2010 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.
↑ Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. पृ॰ 145-146. आई॰ऍस॰बी॰ऍन॰ 0-471-04328-1.
↑ Dustin, Elfriede (2002). Effective Software Testing. Addison Wesley. पृ॰ 3. आई॰ऍस॰बी॰ऍन॰ 0-20179-429-2.
↑ Pan, Jiantao (Spring 1999), "Software Testing (18-849b Dependable Embedded Systems)", Topics in Dependable Embedded Systems, Electrical and Computer Engineering Department, Carnegie Mellon University, मूल से 25 दिसंबर 2009 को पुरालेखित, अभिगमन तिथि 28 दिसंबर 2009
↑ IEEE (1998). IEEE standard for software test documentation. New York: IEEE. आई॰ऍस॰बी॰ऍन॰ 0-7381-1443-X.
↑ Kaner, Cem (2001). "NSF grant proposal to "lay a foundation for significant improvements in the quality of academic and commercial courses in software testing"" (PDF). मूल (pdf) से 27 नवंबर 2009 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.
↑ Kaner, Cem (2003). "Measuring the Effectiveness of Software Testers" (PDF). मूल (pdf) से 26 मार्च 2010 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.
↑ Black, Rex (December 2008). Advanced Software Testing- Vol. 2: Guide to the ISTQB Advanced Certification as an Advanced Test Manager. Santa Barbara: Rocky Nook Publisher. आई॰ऍस॰बी॰ऍन॰ 1933952369.
↑ ^अ ^आ ^इ ^ई ^उ "Quality Assurance Institute". मूल से 1 अक्तूबर 2012 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.
↑ ^अ ^आ "International Institute for Software Testing". मूल से 23 दिसंबर 2009 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.
↑ "K. J. Ross & Associates". मूल से 15 फ़रवरी 2008 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.
↑ ^अ ^आ "ISTQB". मूल से 10 फ़रवरी 2010 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.
↑ ^अ ^आ "ISTQB in the U.S." मूल से 8 मार्च 2010 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.
↑ "EXIN: Examination Institute for Information Science". मूल से 29 मार्च 2010 को पुरालेखित. अभिगमन तिथि 15 जून 2020.
↑ ^अ ^आ "American Society for Quality". मूल से 13 दिसंबर 2009 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.
↑ "context-driven-testing.com". मूल से 7 नवंबर 2011 को पुरालेखित. अभिगमन तिथि 15 जून 2020.
↑ "Article on taking agile traits without the agile method". मूल से 25 दिसंबर 2009 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.
↑ “We’re all part of the story” Archived 2009-08-31 at the वेबैक मशीन डेविड स्ट्रोम द्वारा, 1 जुलाई 2009
↑ IEEE article about differences in adoption of agile trends between experienced managers vs. young students of the Project Management Institute. Archived 2019-02-17 at the वेबैक मशीन Agile adoption study from 2007 Archived 2008-12-17 at the वेबैक मशीन भी देखें
↑ "Agile software development practices slowly entering the military". मूल से 25 जनवरी 2010 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.
↑ IEEE article on Exploratory vs. Non Exploratory testing
↑ एक उदाहरण हैं मार्क फ्युस्टर, डोरोथी ग्राहम: सॉफ्टवेयर टेस्ट ऑटोमेशन एडिसन वेस्ले, 1999, ISBN 0-201-33140-3.
↑ "Article referring to other links questioning the necessity of unit testing". मूल से 5 जनवरी 2010 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.
↑ "Microsoft Development Network Discussion on exactly this topic". मूल से 15 फ़रवरी 2010 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

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

[1] Exploratory Testing Archived 2009-01-26 at the वेबैक मशीन सेम केनर, फ्लॉरिडा प्रौद्योगिकी संस्थान, क्वालिटी अश्योरेन्स इंस्टीट्यूट वर्ल्डवाइड सॉफ्टवेयर परीक्षण कॉन्फरेंस ऑरलैंडो, FL, नवम्बर, 2006

[2] लेटनर, ए, सिउपा, I, ओरिअल, एम, मेयेर, बी, फिवा, ए, "Contract Driven Development = Test Driven Development - Writing Test Cases" Archived 2017-06-30 at the वेबैक मशीन ESEC/FSE07 की कार्यवाही: सॉफ्टवेयर इंजीनियरिंग के आधार पर यूरोपीय सॉफ्टवेयर इंजीनियरिंग सम्मेलन और ACM SIGSOFT संगोष्ठी, 2007, (डबरोवनिक, क्रोएशिया), सितम्बर, 2007

[3] Software errors cost U.S. economy $59.5 billion annually Archived 2013-01-22 at the वेबैक मशीन NIST रिपोर्ट

[Myers_1979-4] अ ^आ Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. आई॰ऍस॰बी॰ऍन॰ 0-471-04328-1. मूल से 18 सितंबर 2019 को पुरालेखित. अभिगमन तिथि 23 अक्तूबर 2019.

[5] Dr. Dobb's journal of software tools for the professional programmer. M&T Pub. 12 (1–6): 116. 1987 "a+successful+test+is+one+that+finds+a+bug&dq="a+successful+test+is+one+that+finds+a+bug&ei=U44OSsOxBpKSzgSxo4mXAg&pgis=1 http://books.google.com/books?id=7RoIAAAAIAAJ&q="a+successful+test+is+one+that+finds+a+bug&dq="a+successful+test+is+one+that+finds+a+bug&ei=U44OSsOxBpKSzgSxo4mXAg&pgis=1. गायब अथवा खाली |title= (मदद)

[6] Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)

[7] 1956 तक यह डीबगिंग उन्मुख अवधि थी, जब परीक्षण को अक्सर डीबगिंग से संबद्ध किया गया था: डीबगिंग और परीक्षण के बीच कोई स्पष्ट अन्तर मौजूद नहीं था। Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)

[8] 1957-1978 तक, प्रदर्शन उन्मुख अवधि थी, जहाँ डीबगिंग और परीक्षण अब प्रतिष्ठित थे - इस अवधि में यह दिखा कि सॉफ्टवेयर आवश्यकताओं को संतुष्ट करता है। Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)

[9] 1979-1982 के बीच के समय को विनाश उन्मुख अवधि कहा गया, जहाँ लक्ष्य त्रुटि खोजने का था। Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)

[10] 1983-1987 का वर्गीकरण मूल्यांकन उन्मुख अवधि के रूप में किया गया है: उद्देश्य यह है कि सॉफ्टवेयर के जीवन चक्र के दौरान उत्पाद मूल्यांकन और मापन गुणवत्ता प्रदान की जाती है। Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)

[Gelperin_1988-11] अ ^आ 1988 से इसे सुरक्षा उन्मुख अवधि के रूप में देखा गया, जहाँ परीक्षण यह दिखाते थे कि सॉफ्टवेयर अपने विनिर्देशन को संतुष्ट करता है, दोष का पता लगाना और दोष को रोकना। Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)

[Kaner1-12] अ ^आ ^इ Kaner, Cem (1999). Testing Computer Software, 2nd Ed. New York, et al: John Wiley and Sons, Inc. पपृ॰ 480 pages. आई॰ऍस॰बी॰ऍन॰ 0-471-35846-0. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद) सन्दर्भ त्रुटि: <ref> अमान्य टैग है; "Kaner1" नाम कई बार विभिन्न सामग्रियों में परिभाषित हो चुका है

[kolawa-13] Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. पृ॰ 41-43. आई॰ऍस॰बी॰ऍन॰ 0470042125. मूल से 25 अप्रैल 2012 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद); |pages= और |page= के एक से अधिक मान दिए गए हैं (मदद)

[14] Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. पृ॰ 86. आई॰ऍस॰बी॰ऍन॰ 0470042125. मूल से 25 अप्रैल 2012 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद); |pages= और |page= के एक से अधिक मान दिए गए हैं (मदद)

[ctfl-15] अ ^आ धारा 1.1.2, Certified Tester Foundation Level Syllabus Archived 2008-12-17 at the वेबैक मशीन इंटरनेशनल सॉफ्टवेयर परीक्षण योग्यता बोर्ड

[16] Kaner, Cem (2001). Lessons Learned in Software Testing: A Context-Driven Approach. Wiley. पृ॰ 4. आई॰ऍस॰बी॰ऍन॰ 0-471-08112-4. नामालूम प्राचल |coauthors= की उपेक्षा की गयी (|author= सुझावित है) (मदद)

[17] McConnell, Steve (2004). Code Complete (2nd संस्करण). Microsoft Press. पपृ॰ 960. आई॰ऍस॰बी॰ऍन॰ 0-7356-1967-0.

[18] सिद्धांत 2, धारा 1.3, Certified Tester Foundation Level Syllabus Archived 2008-12-17 at the वेबैक मशीन अन्तर्राष्ट्रीय सॉफ्टवेयर परीक्षण योग्यता बोर्ड

[tran-19] Tran, Eushiuan (1999). "Verification/Validation/Certification". प्रकाशित Koopman, P. (संपा॰). Topics in Dependable Embedded Systems. USA: Carnegie Mellon University. अभिगमन तिथि 2008-01-13.

[20] Laycock, G. T.. "The Theory and Practice of Specification Based Software Testing" (PostScript). Dept of Computer Science, Sheffield University, UK. अभिगमन तिथि: Archived 2007-02-14 at the वेबैक मशीन "संग्रहीत प्रति". मूल से 14 फ़रवरी 2007 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

[21] Bach, James (1999). "Risk and Requirements-Based Testing" (PDF). Computer. 32 (6): 113–114. मूल (PDF) से 29 दिसंबर 2009 को पुरालेखित. अभिगमन तिथि 2008-08-19. नामालूम प्राचल |month= की उपेक्षा की गयी (मदद)

[22] Savenkov, Roman (2008). How to Become a Software Tester. Roman Savenkov Consulting. पृ॰ 168. आई॰ऍस॰बी॰ऍन॰ 978-0-615-23372-7.

[23] Introduction Archived 2009-12-27 at the वेबैक मशीन कोड कवरेज विश्लेषण, स्टीव कार्नेट

[24] Binder, Robert V. (1999). Testing Object-Oriented Systems: Objects, Patterns, and Tools. Addison-Wesley Professional. पृ॰ 45. आई॰ऍस॰बी॰ऍन॰ 0-201-80938-9.

[25] Beizer, Boris (1990). Software Testing Techniques (Second संस्करण). New York: Van Nostrand Reinhold. पपृ॰ 21, 430. आई॰ऍस॰बी॰ऍन॰ 0-442-20672-0.

[ieee-26] IEEE (1990). IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York: IEEE. आई॰ऍस॰बी॰ऍन॰ 1559370793.

[27] "e)Testing Phase in Software Testing:-". मूल से 24 जुलाई 2010 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

[28] Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. पृ॰ 145-146. आई॰ऍस॰बी॰ऍन॰ 0-471-04328-1.

[29] Dustin, Elfriede (2002). Effective Software Testing. Addison Wesley. पृ॰ 3. आई॰ऍस॰बी॰ऍन॰ 0-20179-429-2.

[30] Pan, Jiantao (Spring 1999), "Software Testing (18-849b Dependable Embedded Systems)", Topics in Dependable Embedded Systems, Electrical and Computer Engineering Department, Carnegie Mellon University, मूल से 25 दिसंबर 2009 को पुरालेखित, अभिगमन तिथि 28 दिसंबर 2009

[31] IEEE (1998). IEEE standard for software test documentation. New York: IEEE. आई॰ऍस॰बी॰ऍन॰ 0-7381-1443-X.

[32] Kaner, Cem (2001). "NSF grant proposal to "lay a foundation for significant improvements in the quality of academic and commercial courses in software testing"" (PDF). मूल (pdf) से 27 नवंबर 2009 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

[33] Kaner, Cem (2003). "Measuring the Effectiveness of Software Testers" (PDF). मूल (pdf) से 26 मार्च 2010 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

[34] Black, Rex (December 2008). Advanced Software Testing- Vol. 2: Guide to the ISTQB Advanced Certification as an Advanced Test Manager. Santa Barbara: Rocky Nook Publisher. आई॰ऍस॰बी॰ऍन॰ 1933952369.

[Quality_Assurance_Institute-35] अ ^आ ^इ ^ई ^उ "Quality Assurance Institute". मूल से 1 अक्तूबर 2012 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

[testinginstitute.com-36] अ ^आ "International Institute for Software Testing". मूल से 23 दिसंबर 2009 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

[37] "K. J. Ross & Associates". मूल से 15 फ़रवरी 2008 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

[istqb-38] अ ^आ "ISTQB". मूल से 10 फ़रवरी 2010 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

[astqb-39] अ ^आ "ISTQB in the U.S." मूल से 8 मार्च 2010 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

[40] "EXIN: Examination Institute for Information Science". मूल से 29 मार्च 2010 को पुरालेखित. अभिगमन तिथि 15 जून 2020.

[American_Society_for_Quality-41] अ ^आ "American Society for Quality". मूल से 13 दिसंबर 2009 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

[42] "context-driven-testing.com". मूल से 7 नवंबर 2011 को पुरालेखित. अभिगमन तिथि 15 जून 2020.

[43] "Article on taking agile traits without the agile method". मूल से 25 दिसंबर 2009 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

[44] “We’re all part of the story” Archived 2009-08-31 at the वेबैक मशीन डेविड स्ट्रोम द्वारा, 1 जुलाई 2009

[45] IEEE article about differences in adoption of agile trends between experienced managers vs. young students of the Project Management Institute. Archived 2019-02-17 at the वेबैक मशीन Agile adoption study from 2007 Archived 2008-12-17 at the वेबैक मशीन भी देखें

[46] "Agile software development practices slowly entering the military". मूल से 25 जनवरी 2010 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

[47] IEEE article on Exploratory vs. Non Exploratory testing

[48] एक उदाहरण हैं मार्क फ्युस्टर, डोरोथी ग्राहम: सॉफ्टवेयर टेस्ट ऑटोमेशन एडिसन वेस्ले, 1999, ISBN 0-201-33140-3.

[49] "Article referring to other links questioning the necessity of unit testing". मूल से 5 जनवरी 2010 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

[50] "Microsoft Development Network Discussion on exactly this topic". मूल से 15 फ़रवरी 2010 को पुरालेखित. अभिगमन तिथि 28 दिसंबर 2009.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]