यह ट्यूटोरियल सात बुनियादी सॉफ्टवेयर परीक्षण सिद्धांतों का परिचय देता है जो प्रत्येक सॉफ्टवेयर परीक्षक और QA पेशेवर को पता होना चाहिए।
सॉफ्टवेयर परीक्षण के 7 सिद्धांत
- परीक्षण दोषों की उपस्थिति दर्शाता है
- थकावट का परीक्षण संभव नहीं है
- प्रारंभिक परीक्षण
- गुच्छेदार दोष
- कीटनाशक विरोधाभास
- परीक्षण संदर्भ पर निर्भर है
- त्रुटियों के अभाव की अनुपस्थिति
आइए निम्न वीडियो उदाहरण के साथ परीक्षण सिद्धांतों को जानें-
यदि वीडियो उपलब्ध नहीं है तो यहां क्लिक करें
पृष्ठभूमि
यह महत्वपूर्ण है कि आप लक्ष्य से विचलित हुए बिना सॉफ़्टवेयर परीक्षण का संचालन करते हुए इष्टतम परीक्षा परिणाम प्राप्त करें। लेकिन आप कैसे निर्धारित करते हैं कि आप परीक्षण के लिए सही रणनीति का पालन कर रहे हैं? उसके लिए, आपको कुछ बुनियादी परीक्षण सिद्धांतों से चिपके रहने की आवश्यकता है। यहां सात सामान्य परीक्षण सिद्धांत हैं जो सॉफ्टवेयर उद्योग में व्यापक रूप से प्रचलित हैं।
इसे समझने के लिए, एक परिदृश्य पर विचार करें जहां आप फ़ोल्डर ए से फोल्डर बी तक एक फ़ाइल स्थानांतरित कर रहे हैं।
उन सभी संभावित तरीकों के बारे में सोचें जो आप इस पर परीक्षण कर सकते हैं।
सामान्य परिदृश्यों के अलावा, आप निम्न स्थितियों का भी परीक्षण कर सकते हैं
- ओपन होने पर फ़ाइल को स्थानांतरित करने की कोशिश कर रहा है
- फ़ोल्डर B में फ़ाइल पेस्ट करने के लिए आपके पास सुरक्षा अधिकार नहीं हैं
- फोल्डर बी एक साझा ड्राइव पर है और भंडारण क्षमता भरी हुई है।
- फ़ोल्डर बी में पहले से ही समान नाम वाली एक फ़ाइल है, वास्तव में, सूची अंतहीन है
- या मान लें कि आपके पास परीक्षण करने के लिए 15 इनपुट फ़ील्ड हैं, प्रत्येक में 5 संभावित मान हैं, परीक्षण किए जाने वाले संयोजनों की संख्या 5 15 होगी
यदि आप संपूर्ण संभव संयोजन परियोजना का परीक्षण करने के लिए थे, तो समय और COSTS में तेजी से वृद्धि होगी। परीक्षण प्रयास को अनुकूलित करने के लिए हमें कुछ सिद्धांतों और रणनीतियों की आवश्यकता है
यहाँ 7 सिद्धांत दिए गए हैं:
1) अत्यधिक परीक्षण संभव नहीं है
हाँ! थकावट का परीक्षण संभव नहीं है। इसके बजाय, हमें आवेदन के जोखिम मूल्यांकन के आधार पर परीक्षण की इष्टतम मात्रा की आवश्यकता है।
और मिलियन डॉलर का सवाल है, आप इस जोखिम को कैसे निर्धारित करते हैं?
इसका उत्तर देने के लिए आइए एक व्यायाम करें
आपकी राय में, आपके ऑपरेटिंग सिस्टम के विफल होने के लिए कौन सा ऑपरेशन सबसे अधिक संभावना है?
मुझे यकीन है कि आप में से अधिकांश ने अनुमान लगाया होगा, एक ही समय में 10 अलग-अलग एप्लिकेशन खोलना।
इसलिए यदि आप इस ऑपरेटिंग सिस्टम का परीक्षण कर रहे थे, तो आपको एहसास होगा कि दोषों को मल्टी-टास्किंग गतिविधि में पाए जाने की संभावना है और पूरी तरह से परीक्षण करने की आवश्यकता है जो हमें हमारे अगले सिद्धांत को दोषपूर्ण क्लस्टरिंग के लिए लाता है।
2) दोष क्लस्टरिंग
दोषपूर्ण क्लस्टरिंग जिसमें कहा गया है कि कम संख्या में मॉड्यूल में अधिकांश दोष पाए जाते हैं। यह सॉफ्टवेयर परीक्षण के लिए पेरेटो सिद्धांत का अनुप्रयोग है: लगभग 80% समस्याएं 20% मॉड्यूल में पाई जाती हैं।
अनुभव से, आप ऐसे जोखिम भरे मॉड्यूल की पहचान कर सकते हैं। लेकिन इस दृष्टिकोण की अपनी समस्याएं हैं
यदि समान परीक्षणों को बार-बार दोहराया जाता है, तो अंतत: समान परीक्षण मामलों में नए बग नहीं मिलेंगे।
3) कीटनाशक विरोधाभास
खेती के दौरान कीड़ों को मिटाने के लिए एक ही कीटनाशक मिश्रण के दोहराए जाने से कीटों पर कीटनाशक का अप्रभावी प्रतिरोध विकसित करने वाले कीटों का समय के साथ असर होगा। सॉफ्टवेयर परीक्षण के लिए भी यही बात लागू होती है। यदि दोहराव परीक्षणों का एक ही सेट आयोजित किया जाता है, तो नए दोषों की खोज के लिए विधि बेकार हो जाएगी।
इसे दूर करने के लिए, परीक्षण के मामलों की नियमित रूप से समीक्षा करने और संशोधित करने की आवश्यकता है, और अधिक दोष खोजने में मदद करने के लिए नए और विभिन्न परीक्षण मामलों को जोड़ते हैं।
परीक्षक केवल मौजूदा परीक्षण तकनीकों पर निर्भर नहीं कर सकते। परीक्षण को और अधिक प्रभावी बनाने के लिए उसे मौजूदा तरीकों को बेहतर बनाने के लिए लगातार देखना चाहिए। लेकिन परीक्षण में यह सब पसीना और कड़ी मेहनत के बाद भी, आप कभी भी अपने उत्पाद को बग-मुक्त करने का दावा नहीं कर सकते। इस बिंदु पर घर चलाने के लिए, आइए विंडोज 98 के सार्वजनिक लॉन्च के इस वीडियो को देखें
आपको लगता है कि MICROSOFT जैसी कंपनी ने अपने OS का पूरी तरह से परीक्षण नहीं किया होगा और अपने सार्वजनिक लॉन्च के दौरान अपने OS को दुर्घटनाग्रस्त होते देखने के लिए अपनी प्रतिष्ठा को जोखिम में डालेगी!
4) परीक्षण दोषों की उपस्थिति को दर्शाता है
इसलिए, परीक्षण सिद्धांत कहता है कि - परीक्षण दोषों की उपस्थिति के बारे में बात करता है और दोषों की अनुपस्थिति के बारे में बात नहीं करता है। सॉफ्टवेयर सॉफ्टवेयर परीक्षण सॉफ्टवेयर में शेष अनदेखे दोषों की संभावना को कम करता है लेकिन यदि कोई दोष नहीं पाया जाता है, तो भी यह शुद्धता का प्रमाण नहीं है।
लेकिन क्या हो, अगर आप अतिरिक्त सावधानी बरतें, सभी सावधानी बरतें और अपने सॉफ़्टवेयर उत्पाद को 99% बग-मुक्त करें। और सॉफ्टवेयर ग्राहकों की जरूरतों और आवश्यकताओं को पूरा नहीं करता है।
यह हमें हमारे अगले सिद्धांत की ओर ले जाता है, जिसमें कहा गया है कि- त्रुटि का अभाव
5) त्रुटि की अनुपस्थिति - गिरावट
यह संभव है कि जो सॉफ्टवेयर 99% बग-फ्री है वह अभी भी अनुपयोगी है। यह तब हो सकता है जब सिस्टम को गलत आवश्यकता के लिए पूरी तरह से परीक्षण किया जाता है। सॉफ्टवेयर परीक्षण केवल दोषों का पता लगाने के लिए नहीं है, बल्कि यह जांचने के लिए भी है कि सॉफ्टवेयर व्यवसाय की जरूरतों को पूरा करता है। एरर का न होना एक फेलैसी है यानी सिस्टम के बेकार होने पर फाइंडिंग और फिक्सिंग दोष मदद नहीं करता है और यह यूजर की जरूरतों और जरूरतों को पूरा नहीं करता है।
इस समस्या को हल करने के लिए, परीक्षण का अगला सिद्धांत बताता है कि प्रारंभिक परीक्षण
6) प्रारंभिक परीक्षण
प्रारंभिक परीक्षण - सॉफ्टवेयर विकास जीवन चक्र में परीक्षण यथासंभव जल्दी शुरू होना चाहिए। ताकि आवश्यकताओं या डिज़ाइन चरण के किसी भी दोष को प्रारंभिक अवस्था में पकड़ लिया जाए। परीक्षण के शुरुआती चरणों में एक दोष को ठीक करना बहुत सस्ता है। लेकिन कितनी जल्दी परीक्षण शुरू करना चाहिए? यह अनुशंसा की जाती है कि आप बग को उसी क्षण ढूंढना शुरू करें जब आवश्यकताओं को परिभाषित किया गया हो। बाद के प्रशिक्षण ट्यूटोरियल में इस सिद्धांत पर अधिक।
7) परीक्षण संदर्भ पर निर्भर है
परीक्षण संदर्भ पर निर्भर है जिसका मूल रूप से मतलब है कि जिस तरह से आप एक ई-कॉमर्स साइट का परीक्षण करते हैं वह उस तरह से अलग होगा जैसे आप शेल्फ एप्लिकेशन से किसी वाणिज्यिक का परीक्षण करते हैं। सभी विकसित सॉफ्टवेयर समान नहीं हैं। आप अनुप्रयोग प्रकार के आधार पर एक अलग दृष्टिकोण, कार्यप्रणाली, तकनीक और परीक्षण के प्रकार का उपयोग कर सकते हैं। उदाहरण के परीक्षण के लिए, खुदरा स्टोर पर कोई भी पीओएस सिस्टम एटीएम मशीन के परीक्षण से अलग होगा।
मिथक: "सिद्धांत केवल संदर्भ के लिए हैं। मैं उन्हें व्यवहार में उपयोग नहीं करूंगा।"
यह बहुत असत्य है। टेस्ट सिद्धांत आपको एक प्रभावी टेस्ट रणनीति बनाने और टेस्ट मामलों को पकड़ने में त्रुटि का मसौदा तैयार करने में मदद करेंगे।
लेकिन परीक्षण सिद्धांतों को सीखना केवल पहली बार गाड़ी चलाना सीखना है।
प्रारंभ में, जब आप ड्राइव करना सीखते हैं, तो आप प्रत्येक और हर चीज पर ध्यान देते हैं जैसे गियर शिफ्ट, स्पीड, क्लच हैंडलिंग आदि, लेकिन अनुभव के साथ, आप बस ड्राइविंग पर ध्यान केंद्रित करते हैं बाकी स्वाभाविक रूप से आता है। ऐसा कि आप कार में अन्य यात्रियों के साथ बातचीत भी करते हैं।
सिद्धांतों के परीक्षण के लिए भी यही सच है। अनुभवी परीक्षकों ने इन सिद्धांतों को एक स्तर तक आंतरिक कर दिया है कि वे उन्हें बिना सोचे-समझे भी लागू कर देते हैं। इसलिए यह मिथक कि सिद्धांतों का व्यवहार में उपयोग नहीं किया जाता है, बस सच नहीं है।
