सॉफ्टवेयर टेस्टिंग - मिथक
नीचे दिए गए सॉफ़्टवेयर परीक्षण के बारे में कुछ सबसे आम मिथक हैं।
मिथक 1: परीक्षण बहुत महंगा है
Reality- एक कहावत है, सॉफ्टवेयर विकास के दौरान परीक्षण के लिए कम भुगतान करें या बाद में रखरखाव या सुधार के लिए अधिक भुगतान करें। प्रारंभिक परीक्षण से कई पहलुओं में समय और लागत दोनों की बचत होती है, हालांकि परीक्षण के बिना लागत को कम करने से सॉफ्टवेयर अनुप्रयोग का अनुचित डिजाइन हो सकता है जिससे उत्पाद बेकार हो जाएगा।
मिथक 2: परीक्षण समय-उपभोक्ता है
Reality- एसडीएलसी चरणों के दौरान, परीक्षण कभी भी समय लेने वाली प्रक्रिया नहीं है। हालाँकि उचित परीक्षण के दौरान पहचानी गई त्रुटियों का निदान करना और उन्हें ठीक करना एक समय लेने वाली लेकिन उत्पादक गतिविधि है।
मिथक 3: केवल पूरी तरह से विकसित उत्पादों का परीक्षण किया जाता है
Reality- इसमें कोई संदेह नहीं है, परीक्षण स्रोत कोड पर निर्भर करता है लेकिन आवश्यकताओं की समीक्षा करना और विकसित मामलों की जाँच करना विकसित कोड से स्वतंत्र है। हालांकि विकास जीवन चक्र मॉडल के रूप में पुनरावृत्त या वृद्धिशील दृष्टिकोण पूरी तरह से विकसित सॉफ्टवेयर पर परीक्षण की निर्भरता को कम कर सकता है।
मिथक 4: पूर्ण परीक्षण संभव है
Reality- यह एक मुद्दा बन जाता है जब एक ग्राहक या परीक्षक सोचता है कि पूर्ण परीक्षण संभव है। यह संभव है कि टीम द्वारा सभी रास्तों का परीक्षण किया गया हो लेकिन पूर्ण परीक्षण की घटना कभी संभव नहीं है। सॉफ्टवेयर विकास जीवन चक्र के दौरान कुछ परिदृश्य हो सकते हैं जो परीक्षण टीम या क्लाइंट द्वारा कभी निष्पादित नहीं किए जाते हैं और परियोजना को तैनात किए जाने के बाद निष्पादित किया जा सकता है।
मिथक 5: एक टेस्टेड सॉफ्टवेयर बग-फ्री है
Reality - यह एक बहुत ही सामान्य मिथक है जो क्लाइंट, प्रोजेक्ट मैनेजर और प्रबंधन टीम में विश्वास करता है। कोई भी व्यक्ति पूर्ण निश्चितता के साथ यह दावा नहीं कर सकता है कि एक सॉफ्टवेयर एप्लीकेशन 100% बग-मुक्त है भले ही शानदार परीक्षण कौशल वाले एक परीक्षक ने आवेदन का परीक्षण किया हो। ।
मिथक 6: मिस्ड डिफेक्ट्स टेस्टर्स के कारण हैं
Reality- यह परीक्षण किए जाने के बाद भी आवेदन में बने बगों के लिए परीक्षकों को दोष देने के लिए एक सही दृष्टिकोण नहीं है। यह मिथक समय, लागत और आवश्यकताओं से संबंधित है और बाधाओं को बदल रहा है। हालाँकि परीक्षण की रणनीति के परिणामस्वरूप परीक्षण टीम द्वारा की गई चूक हो सकती है।
मिथक 7: उत्पाद की गुणवत्ता के लिए परीक्षक जिम्मेदार हैं
Reality- यह एक बहुत ही सामान्य गलत व्याख्या है कि उत्पाद की गुणवत्ता के लिए केवल परीक्षक या परीक्षण टीम जिम्मेदार होना चाहिए। परीक्षकों की जिम्मेदारियों में हितधारकों के लिए बग की पहचान शामिल है और फिर यह उनका निर्णय है कि वे बग को ठीक करेंगे या सॉफ्टवेयर को जारी करेंगे। समय पर सॉफ्टवेयर जारी करना परीक्षकों पर अधिक दबाव डालता है, क्योंकि उन्हें किसी भी त्रुटि के लिए दोषी ठहराया जाएगा।
मिथक 8: टेस्ट ऑटोमेशन का इस्तेमाल जहां भी संभव हो समय कम करना चाहिए
Reality- हां, यह सच है कि टेस्ट ऑटोमेशन से परीक्षण का समय कम हो जाता है, लेकिन सॉफ्टवेयर विकास के दौरान किसी भी समय टेस्ट ऑटोमेशन शुरू करना संभव नहीं है। टेस्ट ऑटोमेटन को शुरू किया जाना चाहिए जब सॉफ्टवेयर को मैन्युअल रूप से परीक्षण किया गया है और कुछ हद तक स्थिर है। इसके अलावा, यदि आवश्यकताएं बदलती रहें तो परीक्षण स्वचालन का उपयोग कभी नहीं किया जा सकता है।
मिथक 9: कोई भी एक सॉफ्टवेयर एप्लिकेशन का परीक्षण कर सकता है
Reality- आईटी इंडस्ट्री से बाहर के लोग सोचते हैं और यहां तक कि यह भी मानते हैं कि कोई भी एक सॉफ्टवेयर का परीक्षण कर सकता है और परीक्षण एक रचनात्मक काम नहीं है। हालाँकि परीक्षकों को अच्छी तरह पता है कि यह एक मिथक है। वैकल्पिक परिदृश्यों के बारे में सोचते हुए, संभावित बगों का पता लगाने के इरादे से एक सॉफ्टवेयर को क्रैश करने का प्रयास करें, इसे विकसित करने वाले व्यक्ति के लिए संभव नहीं है।
मिथक 10: ए टेस्टर का एकमात्र टास्क है, फाइंड बग्स
Reality- एक सॉफ्टवेयर में बग ढूंढना परीक्षकों का काम है, लेकिन साथ ही, वे विशेष सॉफ्टवेयर के डोमेन विशेषज्ञ हैं। डेवलपर्स केवल उस विशिष्ट घटक या क्षेत्र के लिए जिम्मेदार हैं जो उन्हें सौंपा गया है लेकिन परीक्षक सॉफ्टवेयर के समग्र कामकाज को समझते हैं, निर्भरताएं क्या हैं, और एक मॉड्यूल के प्रभाव दूसरे मॉड्यूल पर हैं।