सॉफ्टवेयर परीक्षण के 7 सिद्धांत उदाहरणों के साथ

यह ट्यूटोरियल सात बुनियादी सॉफ्टवेयर परीक्षण सिद्धांतों का परिचय देता है जिन्हें प्रत्येक सॉफ्टवेयर परीक्षक और QA पेशेवर को जानना चाहिए।

आइये निम्नलिखित के माध्यम से परीक्षण के सिद्धांतों को जानें वीडियो उदाहरण-

क्लिक करें यहाँ उत्पन्न करें यदि वीडियो उपलब्ध न हो

पृष्ठभूमि

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

इसे समझने के लिए, एक परिदृश्य पर विचार करें जहां आप किसी फ़ाइल को फ़ोल्डर A से फ़ोल्डर B में ले जा रहे हैं।

उन सभी संभावित तरीकों के बारे में सोचें जिनसे आप इसका परीक्षण कर सकते हैं।

सामान्य परिदृश्यों के अलावा, आप निम्नलिखित स्थितियों का भी परीक्षण कर सकते हैं

• फ़ाइल खुली होने पर उसे स्थानांतरित करने का प्रयास करना
• आपके पास फ़ोल्डर B में फ़ाइल चिपकाने के लिए सुरक्षा अधिकार नहीं हैं
• फ़ोल्डर B साझा ड्राइव पर है और संग्रहण क्षमता पूर्ण है.
• फ़ोल्डर B में पहले से ही समान नाम वाली एक फ़ाइल है, वास्तव में, सूची अंतहीन है
• या मान लीजिए कि आपके पास परीक्षण के लिए 15 इनपुट फ़ील्ड हैं, जिनमें से प्रत्येक में 5 संभावित मान हैं, तो परीक्षण किए जाने वाले संयोजनों की संख्या 5^15 होगी

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

ये हैं 7 सिद्धांत:

1) संपूर्ण परीक्षण संभव नहीं है

हाँ! संपूर्ण परीक्षण संभव नहीं है। इसके बजाय, हमें आवेदन के जोखिम मूल्यांकन के आधार पर इष्टतम मात्रा में परीक्षण की आवश्यकता है।

और सबसे बड़ा सवाल यह है कि आप इस जोखिम का निर्धारण कैसे करेंगे?

इसका उत्तर जानने के लिए आइए एक अभ्यास करें

आपकी राय में, कौन सा ऑपरेशन आपके लिए सबसे अधिक परेशानी का कारण बनेगा? Operaक्या आप सिस्टम को विफल करना चाहते हैं?

मुझे यकीन है कि आप में से अधिकांश ने अनुमान लगाया होगा कि एक ही समय में 10 अलग-अलग एप्लिकेशन खोलना।

तो अगर आप इसका परीक्षण कर रहे थे Operaसिस्टम को समझने के बाद, आप महसूस करेंगे कि मल्टी-टास्किंग गतिविधि में दोष पाए जाने की संभावना है और इसका पूरी तरह से परीक्षण करने की आवश्यकता है जो हमें हमारे अगले सिद्धांत पर लाता है दोष Clusterआईएनजी

2) दोष Clusterआईएनजी

दोष Clusterजिसमें कहा गया है कि कुछ ही मॉड्यूल में अधिकांश दोष पाए गए हैं। यह सॉफ्टवेयर परीक्षण में पेरेटो सिद्धांत का अनुप्रयोग है: लगभग 80% समस्याएँ 20% मॉड्यूल में पाई जाती हैं।

अनुभव से आप ऐसे जोखिम भरे मॉड्यूल की पहचान कर सकते हैं। लेकिन इस दृष्टिकोण की अपनी समस्याएं हैं

यदि एक ही परीक्षण को बार-बार दोहराया जाए, तो अंततः उन्हीं परीक्षण मामलों में नए बग नहीं मिलेंगे।

3) कीटनाशक विरोधाभास

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

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

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

क्या आप सोचते हैं कि माइक्रोसॉफ्ट जैसी कंपनी ने अपने ऑपरेटिंग सिस्टम का गहन परीक्षण नहीं किया होगा और अपनी प्रतिष्ठा को जोखिम में डाला होगा, सिर्फ इसलिए कि सार्वजनिक लॉन्च के दौरान उसका ऑपरेटिंग सिस्टम क्रैश हो गया!

4) परीक्षण से दोषों की उपस्थिति का पता चलता है

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

लेकिन क्या होगा अगर आप अतिरिक्त मेहनत करते हैं, सभी सावधानियां बरतते हैं और अपने सॉफ्टवेयर उत्पाद को 99% बग-मुक्त बनाते हैं। और सॉफ्टवेयर ग्राहकों की जरूरतों और आवश्यकताओं को पूरा नहीं करता है।

यह हमें हमारे अगले सिद्धांत की ओर ले जाता है, जो कहता है कि - त्रुटि का अभाव

5) त्रुटि का अभाव – भ्रांति

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

इस समस्या को हल करने के लिए, परीक्षण का अगला सिद्धांत कहता है कि प्रारंभिक परीक्षण

6) प्रारंभिक परीक्षण

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

7) परीक्षण संदर्भ पर निर्भर है

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

मिथक: "सिद्धांत केवल संदर्भ के लिए हैं। मैं उन्हें व्यवहार में उपयोग नहीं करूंगा।"

यह बिलकुल झूठ है। टेस्ट सिद्धांत आपको एक प्रभावी टेस्ट बनाने में मदद करेंगे। टेस्ट रणनीति और ड्राफ्ट त्रुटि पकड़ने वाले परीक्षण मामले।

लेकिन परीक्षण के सिद्धांतों को सीखना ठीक वैसा ही है जैसे पहली बार गाड़ी चलाना सीखना।

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

परीक्षण सिद्धांतों के लिए भी यही बात सच है। अनुभवी परीक्षकों ने इन सिद्धांतों को इस स्तर तक आत्मसात कर लिया है कि वे बिना सोचे-समझे भी उन्हें लागू कर देते हैं। इसलिए यह मिथक कि सिद्धांतों का व्यवहार में उपयोग नहीं किया जाता है, बिल्कुल सच नहीं है।