7 principles software testing
सॉफ्टवेयर टेस्टिंग के सात सिद्धांत: दोषपूर्ण क्लस्टरिंग के बारे में अधिक विवरण सहित, पेरेटो सिद्धांत और कीटनाशक विरोधाभास।
मुझे यकीन है कि हर कोई “के बारे में जानता है सॉफ्टवेयर परीक्षण के सात सिद्धांत ”।
ये मूलभूत परीक्षण सिद्धांत परीक्षण टीमों को अपने समय और प्रयास का उपयोग करने में मदद करते हैं ताकि परीक्षण प्रक्रिया को प्रभावी बनाया जा सके। इस लेख में, हम दो सिद्धांतों के बारे में विस्तार से जानेंगे अर्थात् दोषपूर्ण क्लस्टरिंग, पेरेटो सिद्धांत और कीटनाशक विरोधाभास ।
आप क्या सीखेंगे:
- सॉफ्टवेयर परीक्षण के सात सिद्धांत
सॉफ्टवेयर परीक्षण के सात सिद्धांत
उन दो सिद्धांतों को गहराई से देखने से पहले, आइए हम सॉफ्टवेयर परीक्षण के सात सिद्धांतों को संक्षेप में समझें।
आइए ढूंढते हैं!!
# 1) परीक्षण दोषों की उपस्थिति को दर्शाता है
प्रत्येक एप्लिकेशन या उत्पाद को विभिन्न टीमों द्वारा पर्याप्त मात्रा में परीक्षण के बाद उत्पादन में जारी किया जाता है या सिस्टम एकीकरण परीक्षण, उपयोगकर्ता स्वीकृति परीक्षण और बीटा परीक्षण आदि जैसे विभिन्न चरणों से गुजरता है।
इसलिए क्या आपने कभी किसी परीक्षण टीम को देखा या सुना है कि उन्होंने सॉफ्टवेयर का पूरी तरह से परीक्षण किया है और सॉफ्टवेयर में कोई खराबी नहीं है ? इसके बजाय, प्रत्येक परीक्षण टीम इस बात की पुष्टि करती है कि सॉफ्टवेयर सभी व्यावसायिक आवश्यकताओं को पूरा करता है और यह अंतिम उपयोगकर्ता की जरूरतों के अनुसार कार्य कर रहा है।
सॉफ़्टवेयर परीक्षण उद्योग में, कोई भी यह नहीं कहेगा कि वहाँ है कोई दोष नहीं सॉफ्टवेयर में, जो परीक्षण के रूप में काफी सही है, यह साबित नहीं कर सकता है कि सॉफ्टवेयर त्रुटि मुक्त या दोष-मुक्त है।
हालांकि, परीक्षण का उद्देश्य विभिन्न तकनीकों और विधियों का उपयोग करके अधिक से अधिक छिपे हुए दोषों का पता लगाना है। परीक्षण अनदेखा दोषों को प्रकट कर सकता है और यदि कोई दोष नहीं पाया जाता है, तो इसका मतलब यह नहीं है कि सॉफ़्टवेयर मुक्त दोष है।
उदाहरण 1 :
बैंकिंग एप्लिकेशन पर विचार करें, इस एप्लिकेशन का पूरी तरह से परीक्षण किया गया है और परीक्षण के विभिन्न चरणों जैसे कि एसआईटी, यूएटी आदि से गुजरता है और वर्तमान में सिस्टम में किसी भी दोष की पहचान नहीं की गई है।
हालांकि, ऐसी संभावना हो सकती है कि उत्पादन के माहौल में, वास्तविक ग्राहक एक कार्यक्षमता की कोशिश करता है जो बैंकिंग प्रणाली में शायद ही कभी उपयोग की जाती है और परीक्षकों ने उस कार्यक्षमता की अनदेखी की है, इसलिए आज तक कोई भी दोष नहीं पाया गया या कोड को कभी भी डेवलपर्स द्वारा नहीं छुआ गया है। ।
उदाहरण 2:
हमने टेलीविजन पर साबुन, टूथपेस्ट, हैंडवाश या कीटाणुनाशक स्प्रे आदि के कई विज्ञापन देखे हैं।
एक हैंडवाश विज्ञापन पर विचार करें जो टेलीविजन पर कहता है कि यदि उस विशिष्ट हैंडवाश का उपयोग किया जाता है तो 99% कीटाणुओं को हटाया जा सकता है। यह स्पष्ट रूप से साबित करता है कि उत्पाद 100% रोगाणु-मुक्त नहीं है। इस प्रकार हमारी परीक्षण अवधारणा में, हम कह सकते हैं कि कोई भी सॉफ्टवेयर दोष मुक्त नहीं है।
# 2) प्रारंभिक परीक्षण
सॉफ़्टवेयर डेवलपमेंट लाइफ साइकिल (SDLC) के शुरुआती चरण में परीक्षकों को शामिल होने की आवश्यकता होती है। इस प्रकार आवश्यकता विश्लेषण चरण या किसी भी प्रलेखन दोष के दौरान दोष की पहचान की जा सकती है। इस तरह के दोषों को ठीक करने में शामिल लागत बहुत कम होती है जब परीक्षण के बाद के चरणों के दौरान पाए जाते हैं।
नीचे की छवि पर विचार करें जो दिखाता है कि लाइव उत्पादन की दिशा में परीक्षण के कदम के रूप में दोष निर्धारण की लागत कैसे बढ़ जाती है।
(छवि स्रोत )
उपरोक्त छवि से पता चलता है कि आवश्यकता विश्लेषण के दौरान पाए गए दोष को ठीक करने के लिए आवश्यक लागत कम है और जब हम परीक्षण या रखरखाव चरण की ओर बढ़ते हैं तो यह बढ़ता ही जाता है।
अब सवाल यह है कितनी जल्दी परीक्षण शुरू करना चाहिए ?
एक बार आवश्यकताओं को अंतिम रूप देने के बाद, परीक्षकों को परीक्षण के लिए शामिल करने की आवश्यकता होती है। परीक्षण को आवश्यकता दस्तावेजों, विनिर्देश या किसी अन्य प्रकार के दस्तावेज़ पर किया जाना चाहिए ताकि यदि आवश्यकताओं को गलत तरीके से परिभाषित किया जाता है तो उन्हें विकास के चरण में ठीक करने के बजाय तुरंत ठीक किया जा सके।
# 3) व्यापक परीक्षण संभव नहीं है
वास्तविक परीक्षण के दौरान इनपुट डेटा के सभी मान्य और अमान्य संयोजनों के साथ सभी कार्यात्मकताओं का परीक्षण करना संभव नहीं है। इस दृष्टिकोण के बजाय, विभिन्न तकनीकों का उपयोग करके कुछ संयोजनों का परीक्षण प्राथमिकता के आधार पर माना जाता है।
व्यापक परीक्षण असीमित प्रयास करेगा और उन प्रयासों में से अधिकांश अप्रभावी हैं। इसके अलावा, परियोजना की समय-सीमा इतनी सारी संयोगों के परीक्षण की अनुमति नहीं देगी। इसलिए यह समान विभाजन और सीमा मूल्य विश्लेषण जैसे विभिन्न तरीकों का उपयोग करके इनपुट डेटा का परीक्षण करने की सिफारिश की जाती है।
उदाहरण के लिए ,यदि मान लें कि हमारे पास एक इनपुट फ़ील्ड है जो केवल 0 से 1000 तक वर्णमाला, विशेष वर्ण और संख्या को स्वीकार करता है। कल्पना कीजिए कि परीक्षण के लिए कितने संयोजन दिखाई देंगे, प्रत्येक इनपुट प्रकार के लिए सभी संयोजनों का परीक्षण करना संभव नहीं है।
परीक्षण के लिए आवश्यक परीक्षण प्रयास बहुत बड़ा होगा और यह परियोजना की समय-सीमा और लागत को भी प्रभावित करेगा। इसलिए यह हमेशा कहा जाता है कि संपूर्ण परीक्षण व्यावहारिक रूप से संभव नहीं है।
# 4) परीक्षण प्रसंग-निर्भर है
बाजार में बैंकिंग, बीमा, चिकित्सा, यात्रा, विज्ञापन आदि जैसे कई डोमेन उपलब्ध हैं और प्रत्येक डोमेन में कई अनुप्रयोग हैं। प्रत्येक डोमेन के लिए, उनके अनुप्रयोगों की अलग-अलग आवश्यकताएं, कार्य, विभिन्न परीक्षण उद्देश्य, जोखिम, तकनीक आदि हैं।
अलग-अलग डोमेन का अलग-अलग परीक्षण किया जाता है, इस प्रकार परीक्षण विशुद्ध रूप से डोमेन या एप्लिकेशन के संदर्भ पर आधारित होता है।
उदाहरण के लिए ,बैंकिंग एप्लिकेशन का परीक्षण किसी भी ई-कॉमर्स या विज्ञापन आवेदन के परीक्षण से अलग है। प्रत्येक प्रकार के एप्लिकेशन से जुड़ा जोखिम अलग-अलग है, इस प्रकार सभी प्रकार के एप्लिकेशन का परीक्षण करने के लिए एक ही विधि, तकनीक और परीक्षण प्रकार का उपयोग करना प्रभावी नहीं है।
# 5) दोषपूर्ण क्लस्टरिंग
परीक्षण के दौरान, ऐसा हो सकता है कि अधिकांश दोष कम संख्या में मॉड्यूल से संबंधित हों। इसके कई कारण हो सकते हैं जैसे कि मॉड्यूल जटिल हो सकते हैं, ऐसे मॉड्यूल से संबंधित कोडिंग जटिल हो सकती है आदि।
यह सॉफ्टवेयर परीक्षण का पेरेटो सिद्धांत है जहां 20% मॉड्यूल में 80% समस्याएं पाई जाती हैं। हम इस लेख में बाद में दोष क्लस्टरिंग और पेरेटो सिद्धांत के बारे में अधिक जानेंगे।
# 6) कीटनाशक विरोधाभास
कीटनाशक विरोधाभास सिद्धांत कहता है कि यदि परीक्षण मामलों के एक ही सेट को बार-बार निष्पादित किया जाता है, तो परीक्षण के ये सेट सिस्टम में नए दोषों की पहचान करने के लिए पर्याप्त सक्षम नहीं हैं।
इस 'कीटनाशक विरोधाभास' को दूर करने के लिए, परीक्षण मामलों के सेट को नियमित रूप से समीक्षा और संशोधित करने की आवश्यकता है। यदि आवश्यक हो तो परीक्षण मामलों के एक नए सेट को जोड़ा जा सकता है और मौजूदा परीक्षण मामलों को हटाया जा सकता है यदि वे सिस्टम से कोई और दोष खोजने में सक्षम नहीं हैं।
# 7) त्रुटि की अनुपस्थिति
यदि सॉफ्टवेयर को पूरी तरह से जांचा जाता है और यदि रिलीज से पहले कोई दोष नहीं पाया जाता है, तो हम कह सकते हैं कि सॉफ्टवेयर 99% दोष मुक्त है। लेकिन क्या होगा अगर इस सॉफ़्टवेयर को गलत आवश्यकताओं के खिलाफ परीक्षण किया जाए? ऐसे मामलों में, यहां तक कि दोषों को खोजने और उन्हें समय पर ठीक करने में मदद नहीं मिलेगी क्योंकि परीक्षण गलत आवश्यकताओं पर किया जाता है जो अंतिम उपयोगकर्ता की जरूरतों के अनुसार नहीं हैं।
उदाहरण के लिए, मान लें कि एप्लिकेशन ई-कॉमर्स साइट और 'शॉपिंग कार्ट या शॉपिंग बास्केट' की कार्यक्षमता से संबंधित है, जिसे गलत तरीके से व्याख्या और परीक्षण किया गया है। यहां, यहां तक कि अधिक दोष खोजने से एप्लिकेशन को अगले चरण में या उत्पादन वातावरण में स्थानांतरित करने में मदद नहीं मिलती है।
सॉफ्टवेयर टेस्टिंग के ये सात सिद्धांत हैं।
अब आइए जानें दोषपूर्ण क्लस्टरिंग, पेरेटो सिद्धांत और कीटनाशक विरोधाभास विस्तार ।
दोषपूर्ण क्लस्टरिंग
किसी भी सॉफ्टवेयर का परीक्षण करते समय, परीक्षक ज्यादातर एक ऐसी स्थिति में आते हैं जिसमें पाए जाने वाले अधिकांश दोष कुछ विशिष्ट कार्यक्षमता से संबंधित होते हैं और बाकी की कार्यक्षमता में कम संख्या में दोष होंगे।
दोषपूर्ण क्लस्टरिंग का मतलब है कम संख्या में मॉड्यूल जिसमें अधिकांश दोष हैं। मूल रूप से, दोषों को पूरे आवेदन में समान रूप से वितरित नहीं किया जाता है, बल्कि दोषों को दो या तीन कार्यात्मकताओं में केंद्रित या केंद्रीकृत किया जाता है।
कई बार, एप्लिकेशन की जटिलता के कारण यह संभव है, कोडिंग जटिल या मुश्किल हो सकती है, एक डेवलपर एक गलती कर सकता है जो केवल एक विशिष्ट कार्यक्षमता या मॉड्यूल को प्रभावित कर सकता है।
दोषपूर्ण क्लस्टरिंग 'पर आधारित है परेतो सिद्धांत “जिसे इस रूप में भी जाना जाता है 80-20 नियम । इसका मतलब है कि 80% दोषों के कारण एप्लिकेशन में 20% मॉड्यूल हैं। पेरेटो सिद्धांत की अवधारणा शुरू में एक इतालवी अर्थशास्त्री द्वारा परिभाषित की गई थी - विलफ्रोडो पेरेटो ।
यदि परीक्षक 100 दोषों को देखते हैं, तो यह स्पष्ट नहीं होगा कि क्या उन 100 दोषों के खिलाफ कोई अंतर्निहित अर्थ है। लेकिन अगर उन 100 दोषों को कुछ विशिष्ट मानदंडों पर वर्गीकृत किया जाता है, तो परीक्षकों के लिए यह समझना संभव है कि बड़ी संख्या में दोष केवल कुछ विशिष्ट मॉड्यूल से संबंधित हैं।
उदाहरण के लिए ,आइए नीचे दी गई छवि पर विचार करें जिसे बैंकिंग एप्लिकेशन में से एक के लिए परीक्षण किया गया है और यह दर्शाता है कि अधिकांश दोष 'ओवरड्राफ्ट' कार्यक्षमता से संबंधित हैं। शेष कार्य जैसे खाता सारांश, निधि अंतरण, स्थायी निर्देश आदि, सीमित संख्या में दोष हैं।
(छवि स्रोत )
उपरोक्त चित्र में कहा गया है कि कुल 32 दोषों में से ओवरड्राफ्ट कार्यक्षमता के आसपास 18 दोष हैं, जिसका अर्थ है कि 60% दोष 'ओवरड्राफ्ट' मॉड्यूल में पाए जाते हैं।
इसलिए, परीक्षक अधिक से अधिक दोष खोजने के लिए निष्पादन के दौरान इस क्षेत्र पर ध्यान केंद्रित करते हैं। यह अनुशंसा की जाती है कि परीक्षण के दौरान परीक्षकों का अन्य मॉड्यूल पर भी समान ध्यान केंद्रित होना चाहिए।
जब एक ही कोड या मॉड्यूल का परीक्षण किया जाता है, तो शुरुआती पुनरावृत्तियों की तुलना में परीक्षण मामलों के एक सेट का उपयोग करते हुए, फिर से, दोषों की संख्या अधिक होती है, हालांकि, कुछ पुनरावृत्ति के बाद, दोष की संख्या काफी कम हो जाएगी। दोषपूर्ण क्लस्टरिंग इंगित करता है कि दोष-प्रवण क्षेत्र को प्रतिगमन परीक्षण के दौरान अच्छी तरह से परीक्षण किया जाना है।
कीटनाशक विरोधाभास
जब मॉड्यूल में से एक में अधिक दोष पाए जाते हैं, तो परीक्षक उस मॉड्यूल का परीक्षण करने के लिए कुछ अतिरिक्त प्रयास करते हैं।
परीक्षण के कुछ पुनरावृत्तियों के बाद, कोड की गुणवत्ता में सुधार होता है और दोष की गिनती कम होने लगती है क्योंकि अधिकांश दोष विकास टीम द्वारा तय किए जाते हैं क्योंकि डेवलपर्स भी एक विशेष मॉड्यूल को कोड करते समय सतर्क रहते हैं जहां परीक्षकों को अधिक दोष मिला।
इसलिए, एक बिंदु पर, अधिकांश दोषों की खोज की जाती है और उन्हें ठीक किया जाता है ताकि कोई नया दोष उस मॉड्यूल में न मिले।
हालाँकि, कई बार ऐसा हो सकता है कि एक विशेष मॉड्यूल पर कोडिंग के दौरान अतिरिक्त सावधानी बरतने के दौरान (यहाँ हमारे मामले में ' ओवरड्राफ्ट 'मॉड्यूल), डेवलपर इसे ठीक से कोड करने के लिए अन्य मॉड्यूल की उपेक्षा कर सकता है या उस विशेष मॉड्यूल में किए गए परिवर्तनों का खाता सारांश, फंड ट्रांसफर और स्थायी निर्देशों जैसी अन्य कार्यात्मकताओं पर नकारात्मक प्रभाव पड़ सकता है।
जब परीक्षक मॉड्यूल को निष्पादित करने के लिए परीक्षण मामलों के एक ही सेट का उपयोग करते हैं, जहां अधिकांश दोष पाए जाते हैं (ओवरड्राफ्ट मॉड्यूल), तब डेवलपर्स द्वारा उन दोषों को ठीक करने के बाद उन नए मामलों को खोजने के लिए परीक्षण के मामले ज्यादा प्रभावी नहीं होते हैं। ओवरड्राफ्ट के अंत से अंत प्रवाह के रूप में, मॉड्यूल को अच्छी तरह से परीक्षण किया जाता है और डेवलपर्स ने उस मॉड्यूल के लिए कोड भी सावधानीपूर्वक लिखा है।
इन परीक्षण मामलों को संशोधित और अद्यतन करना आवश्यक है। नए परीक्षण मामलों को जोड़ना भी एक अच्छा विचार है ताकि सॉफ्टवेयर या एप्लिकेशन के विभिन्न क्षेत्रों में नए और अधिक दोष पाए जा सकें।
कीटनाशक विरोधाभास की रोकथाम के तरीके
दो विकल्प हैं जिनके माध्यम से हम नीचे दिखाए अनुसार कीटनाशक विरोधाभास को रोक सकते हैं:
सेवा मेरे) परीक्षण मामलों का एक नया सेट लिखें, जो विभिन्न क्षेत्र या मॉड्यूल (पहले के दोष प्रवण मॉड्यूल के अलावा) पर केंद्रित होगा - उदाहरण: सॉफ्टवेयर का 'ओवरड्राफ्ट')।
बी) नए परीक्षण मामलों को तैयार करें और मौजूदा परीक्षण मामलों में जोड़ें।
में ' विधि ए परीक्षक, अन्य मॉड्यूल में अधिक दोष पा सकते हैं, जिसमें वे पहले परीक्षण के दौरान केंद्रित नहीं थे या डेवलपर्स कोडिंग के दौरान अतिरिक्त सतर्क नहीं थे।
हमारे उपरोक्त उदाहरण में, परीक्षण मामलों के नए सेट का उपयोग करके परीक्षक खाता सारांश, निधि अंतरण या स्थायी निर्देश मॉड्यूल में अधिक दोष पा सकते हैं।
लेकिन ऐसा हो सकता है कि परीक्षक पहले वाले मॉड्यूल की उपेक्षा कर सकते हैं ( उदाहरण: 'ओवरड्राफ्ट') जहां पहले दोष में अधिकांश दोष पाए गए थे और यह एक जोखिम हो सकता है क्योंकि इस मॉड्यूल (ओवरड्राफ्ट) को अन्य मॉड्यूल के कोडिंग के बाद नए दोषों के साथ इंजेक्ट किया गया हो सकता है।
में ' विधि बी ', नए परीक्षण मामले तैयार किए जाते हैं ताकि नए संभावित दोषों को बाकी मॉड्यूल में पाया जा सके।
हमारे उदाहरण में, नव निर्मित परीक्षण मामले खाता सारांश, निधि अंतरण और स्थायी निर्देश जैसे मॉड्यूल में दोषों की पहचान करने में मदद करेंगे। हालाँकि, परीक्षक पहले दोष प्रवण मॉड्यूल की उपेक्षा नहीं कर सकते ( उदाहरण: 'ओवरड्राफ्ट') क्योंकि इन नए परीक्षण मामलों को मौजूदा परीक्षण मामलों के साथ विलय कर दिया गया है।
मौजूदा परीक्षण मामले 'ओवरड्राफ्ट' मॉड्यूल पर केंद्रित थे और नए परीक्षण मामले अन्य मॉड्यूल पर केंद्रित थे। इसलिए किसी भी मॉड्यूल पर कोड परिवर्तन होने पर कम से कम एक बार परीक्षण मामलों के सभी सेट निष्पादित किए जाते हैं। यह सुनिश्चित करेगा कि उचित प्रतिगमन निष्पादित हो जाता है और इस कोड परिवर्तन के कारण दोष की पहचान की जा सकती है।
दूसरे दृष्टिकोण का उपयोग करते हुए, कुल परीक्षण मामले की गिनती बहुत अधिक हो जाती है और निष्पादन के लिए अधिक प्रयासों और समय की आवश्यकता होती है। यह स्पष्ट रूप से परियोजना की समयसीमा पर और सबसे महत्वपूर्ण रूप से परियोजना बजट पर भी प्रभाव डालेगा।
इसलिए इस समस्या को दूर करने के लिए, निरर्थक परीक्षण मामलों की समीक्षा की जा सकती है और फिर उन्हें हटा दिया जा सकता है। कई परीक्षण मामले हैं जो नए परीक्षण मामलों को जोड़ने और मौजूदा परीक्षण मामलों को संशोधित करने के बाद बेकार हो जाते हैं।
यह जांचना आवश्यक है कि पिछले 5 पुनरावृत्तियों (मान लें 5 पुनरावृत्तियों) में दोषों की पहचान करने के लिए कौन से परीक्षण मामले विफल हैं और कौन से परीक्षण मामले बहुत महत्वपूर्ण नहीं हैं। यह भी हो सकता है कि कुछ परीक्षण मामलों में शामिल एकल प्रवाह को परीक्षण के मामलों को समाप्त करने के लिए दूसरे छोर में कवर किया जा सकता है और एकल प्रवाह वाले उन परीक्षण मामलों को हटाया जा सकता है।
यह, बदले में, कुल परीक्षण मामले की संख्या को कम करेगा।
उदाहरण के लिए ,हमारे पास एक विशेष मॉड्यूल को कवर करने के लिए 50 परीक्षण मामले हैं और हमने देखा है कि इन 50 परीक्षण मामलों में से 20 परीक्षण मामले पिछले कुछ परीक्षण पुनरावृत्तियों में नए दोष का पता लगाने में विफल रहे हैं (मान लें 5 पुनरावृत्तियों)। इसलिए इन 20 परीक्षण मामलों की पूरी तरह से समीक्षा करने की आवश्यकता है और हमें यह जांचने की आवश्यकता है कि ये परीक्षण मामले कितने महत्वपूर्ण हैं और इसके अनुसार निर्णय लिया जा सकता है कि 20 परीक्षण मामलों को रखना है या उन्हें हटाना है।
किसी भी परीक्षण मामले को हटाने से पहले, सत्यापित करें कि उन परीक्षण मामलों में शामिल कार्यक्षमता प्रवाह किसी अन्य परीक्षण मामले में कवर किया गया है। इस प्रक्रिया को सभी मॉड्यूल में पालन करने की आवश्यकता है ताकि कुल परीक्षण मामले की गणना में काफी कमी आए। यह सुनिश्चित करेगा कि परीक्षण मामलों की कुल संख्या कम हो गई है लेकिन अभी भी 100% आवश्यकता कवरेज है।
इसका मतलब है कि सभी शेष परीक्षण मामले सभी व्यावसायिक आवश्यकताओं को कवर करते हैं, इसलिए गुणवत्ता पर कोई समझौता नहीं है।
निष्कर्ष
सॉफ्टवेयर परीक्षण SDLC में एक आवश्यक कदम है क्योंकि यह सत्यापित करता है कि सॉफ्टवेयर प्रति उपयोगकर्ता की जरूरत के अनुसार काम कर रहा है या नहीं।
परीक्षण जितना संभव हो उतना दोष की पहचान करता है। इसलिए प्रभावी रूप से और कुशलता से परीक्षण करने के लिए, सभी को जागरूक होना चाहिए और वास्तव में सॉफ्टवेयर परीक्षण के सात सिद्धांतों को समझना चाहिए, स्पष्ट रूप से वे परीक्षण के लिए स्तंभ के रूप में जाने जाते हैं।
अधिकांश परीक्षकों ने वास्तविक परीक्षण के दौरान इन सिद्धांतों को लागू और अनुभव किया है।
Android के लिए सबसे अच्छा एमपी 3 गाने डाउनलोडर
आम तौर पर, शब्द सिद्धांत का अर्थ उन नियमों या कानूनों से है जिनका पालन करना आवश्यक है। इसलिए, सॉफ़्टवेयर परीक्षण उद्योग में सभी को इन सात सिद्धांतों का पालन करना चाहिए, और यदि कोई भी इन सिद्धांतों को अनदेखा करता है, तो यह परियोजना के लिए भारी खर्च हो सकता है।
पढ़ने का आनंद लो!!
अनुशंसित पाठ
- सर्वश्रेष्ठ सॉफ्टवेयर परीक्षण उपकरण 2021 (क्यूए टेस्ट स्वचालन उपकरण)
- सॉफ्टवेयर परीक्षण क्यूए सहायक नौकरी
- सॉफ्टवेयर टेस्टिंग कोर्स: मुझे किस सॉफ्टवेयर टेस्टिंग इंस्टीट्यूट में शामिल होना चाहिए?
- अपने कैरियर के रूप में सॉफ्टवेयर परीक्षण चुनना
- सॉफ्टवेयर टेस्टिंग टेक्निकल कंटेंट राइटर फ्रीलांसर जॉब
- दोष आधारित परीक्षण तकनीक क्या है?
- कुछ दिलचस्प सॉफ्टवेयर परीक्षण साक्षात्कार प्रश्न
- सॉफ्टवेयर परीक्षण पाठ्यक्रम प्रतिक्रिया और समीक्षा