जोखिम आधारित परीक्षण के लिए अंतिम मार्गदर्शिका: सॉफ्टवेयर परीक्षण में जोखिम प्रबंधन

ultimate guide risk based testing

अंतिम गाइड रिस्क-बेस्ड टेस्टिंग, रिस्क मैनेजमेंट और इसके दृष्टिकोण के साथ उदाहरण:

जोखिम आधारित परीक्षण क्या है?

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

=> पूरी टेस्ट प्लान ट्यूटोरियल सीरीज़ के लिए यहां क्लिक करें

नकारात्मक प्रभाव में लागत प्रभाव, असंतुष्ट ग्राहक, खराब उपयोगकर्ता अनुभव और यहां तक ​​कि ग्राहकों को खोने की सीमा तक शामिल हो सकते हैं।

दूसरे शब्दों में, आरबीटी दृष्टिकोण यह सुनिश्चित करना है कि, परीक्षण इस तरह से किया जाता है कि भले ही उपयोगकर्ता बग ढूंढता है उत्पादन में, जो सॉफ्टवेयर का उपयोग करने से उसे रोक नहीं पाता है या व्यवसाय को गंभीर रूप से प्रभावित नहीं करता है।

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

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

आप क्या सीखेंगे:

• जोखिम-आधारित परीक्षण और इसकी प्रासंगिकता एजाइल और DevOps को
  • जोखिम-आधारित परीक्षण दृष्टिकोण
    • जब हम आरबीटी दृष्टिकोण का उपयोग करते हैं?
    • आरबीटी दृष्टिकोण उदाहरण
  • जोखिम विश्लेषण करने के तरीके
  • जोखिम विश्लेषण प्रक्रिया
  • जोखिम विश्लेषण पद्धति
    • चरण # 1) 3X3 ग्रिड का उपयोग करना
    • चरण # 2) विफलता की संभावना और प्रभाव
    • चरण # 3) प्राथमिकता ग्रिड का परीक्षण करना
    • चरण # 4) परीक्षण का विवरण
  • आरबीटी एजाइल और देवओप्स के लिए प्रासंगिक कैसे है?
  • जोखिम-आधारित परीक्षण दृष्टिकोण के लाभ
• परीक्षण योजना के दौरान जोखिम प्रबंधन
  • जोखिम प्रबंधन प्रक्रिया
    • (1) जोखिम पहचान
    • # 2) जोखिम मूल्यांकन / जोखिम प्रभाव विश्लेषण
    • # 3) जोखिम शमन
  • निष्कर्ष
• परीक्षण निष्पादन चरण में जोखिम प्रबंधन (उदाहरण के साथ)
  • जोखिम प्रबंधन - ऑटो पर ध्यान देने के साथ
  • कैसे जोखिम मामलों का परीक्षण होता है?
  • निष्कर्ष
  • अनुशंसित पाठ

जोखिम-आधारित परीक्षण और इसकी प्रासंगिकता एजाइल और DevOps को

विकासशील सॉफ्टवेयर पर खर्च किए गए तीन सौ घंटों को उत्पादन में पहचाने गए एकल दोष के साथ केवल 30 सेकंड में बेकार किया जा सकता है।

यह बदले में, पूरे उत्पाद के उद्देश्य को बिना किसी अन्य विकल्प के बर्बाद कर सकता है लेकिन सिर्फ इसे बाजार से वापस लेने के लिए। और यही 'गुणवत्ता परीक्षण' के लिए महत्व और आवश्यकता है। '

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

आजकल, सॉफ्टवेयर वितरण में 'गुणवत्ता' एक महत्वपूर्ण कारक बन रहा है, जहां ग्राहकों को खुश रखने के लिए गुणवत्ता में सुधार के लिए निरंतर सुधार हो रहे हैं।

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

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

उपलब्ध समय और संसाधनों के भीतर सीमित और महत्वपूर्ण परीक्षण चलाने के अलावा और कोई विकल्प नहीं है।

तो, हम कैसे तय करते हैं कि इस स्तर पर कौन सा परीक्षण महत्वपूर्ण है? जो कुछ भी एक परीक्षक महत्वपूर्ण मानता है वह वास्तव में ग्राहकों के लिए महत्वपूर्ण नहीं हो सकता है। किसके दृष्टिकोण से सुविधा का महत्व या कार्यक्षमता का निर्णय लिया गया है? कौन तय करेगा कि कौन से महत्वपूर्ण परीक्षण हैं? और बहुत सारे अन्य सवाल उठते रहते हैं।

इन सभी सवालों के जवाब देने और उपरोक्त स्थिति को प्रभावी ढंग से संभालने के लिए, एक परीक्षण दृष्टिकोण कहा जाता है ‘जोखिम-आधारित परीक्षण’ , जल्द ही बुलाया गया 'आरबीटी' , अस्तित्व में आया, जहां टीम ने स्पष्ट रूप से on प्रोजेक्ट रिस्क ’के मानदंडों के आधार पर परीक्षण परिदृश्यों की योजना बनाई और पहचान की।

यद्यपि QA टीम के पास महत्वपूर्ण परीक्षणों की स्पष्ट तस्वीर है, RBT ग्राहक और व्यावसायिक दृष्टिकोण से महत्वपूर्ण और महत्वपूर्ण परीक्षणों की पहचान करने का एक सिद्ध तरीका है 'संकट विश्लेषण' प्रक्रिया ।

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

इसलिए, 'परीक्षण सिद्धांत' की वर्तमान प्रवृत्ति केवल 'दोषों की पहचान' ही नहीं है, बल्कि

# 1) उत्पाद के क्षेत्र पर ध्यान दें जहां उत्पादन में विफलता या उच्च संभावना के कारण व्यवसाय पर उच्च प्रभाव पड़ता है।

#दो) ध्यान रखते हुए दोषों की पहचान करना जल्दी और एक टीम को इसे जल्द से जल्द ठीक करने की अनुमति देता है और इसलिए सॉफ़्टवेयर / उत्पाद या सुविधा को अनुमति देता है ‘फेल फास्ट’।

# 3) क्यूए टीम की सेवा का सबसे महत्वपूर्ण पहलू अब ग्राहक पर ध्यान केंद्रित करने के लिए मूल्य बढ़ाने पर ध्यान केंद्रित करना है 'ग्राहक अनुभव को समाप्त करने के लिए अंत'।

जोखिम-आधारित परीक्षण दृष्टिकोण

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

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

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

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

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

खैर, 4 को परीक्षण में दोषों की सबसे कम प्राथमिकता और गंभीरता माना जाता है। वे परियोजना के अन्य उपयोगी पहलुओं में अपना समय बेहतर निवेश कर सकते हैं।

'जोखिम-आधारित परीक्षण' दृष्टिकोण के प्रमुख ड्राइवरों को संक्षेप में प्रस्तुत करने के लिए:

• व्यावसायिक परिप्रेक्ष्य से enable ग्राहक क्या चाहते हैं ’परीक्षण को सक्षम करने के लिए।
• अपेक्षित गुणवत्ता के साथ समय अनुसूची को पूरा करने के लिए।
• क्यूए प्रयास का अनुकूलन करने के लिए।

जब हम आरबीटी दृष्टिकोण का उपयोग करते हैं?

इसका उपयोग नीचे के परिदृश्यों में किया जाता है:

• जब भी किसी परियोजना की समय, लागत और संसाधनों पर सीमा या बाधा होती है, जब भी संसाधनों का अनुकूलन करने की आवश्यकता होती है, तो आरबीटी दृष्टिकोण का उपयोग किया जा सकता है।
• आरबीटी दृष्टिकोण का उपयोग तब किया जाता है जब कार्यक्रम अधिक जटिल होता है और नई तकनीक को लागू करता है और इसलिए इसमें बहुत सारी चुनौतियां शामिल होती हैं।
• जब प्रोग्राम एक R & D प्रोजेक्ट है और यह पहली तरह का है और प्रोजेक्ट में कई अज्ञात और जोखिम हैं।

आरबीटी दृष्टिकोण उदाहरण

उत्पादन और इसके प्रभाव से होने वाले जोखिमों को दूर करने के लिए आईटी उद्योग में कई जोखिम-आधारित विश्लेषण दृष्टिकोणों का उपयोग किया जाता है।

नीचे एक ऐसा दृष्टिकोण दिया गया है:

आरबीटी के इस दृष्टिकोण में उत्पाद की ional वाइटल फंक्शनलिटीज या प्रमुख विशेषताओं ’की पहचान करना और उन जोखिमों का आकलन करना शामिल है, जिनमें से प्रत्येक कार्यशीलता उत्पादन में कम हो जाती है और जोखिम को कम या कम करने के लिए उचित शमन उपायों को लागू करती है।

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

जोखिम विश्लेषण करने के तरीके

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

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

• विशेषताएं
• कार्यक्षमताओं
• प्रयोक्ता कहानियां
• आवश्यकताओं को
• बक्सों का इस्तेमाल करें
• परीक्षण के मामलों

इस मामले में, हमें केवल जोखिम-आधारित परीक्षण दृष्टिकोण कार्यान्वयन को समझने के लिए परीक्षण मामलों पर ध्यान केंद्रित करना चाहिए।

जोखिम विश्लेषण प्रक्रिया

जोखिम विश्लेषण में involve दोनों से कार्यक्रम के प्रासंगिक हितधारकों की भागीदारी शामिल है तकनीकी टीम और बिजनेस टीम ' , जिसमें उत्पाद का स्वामी, उत्पाद प्रबंधक, व्यवसाय विश्लेषक, आर्किटेक्ट, परीक्षक और ग्राहक प्रतिनिधि शामिल हैं।

इन हितधारकों को शामिल करने वाले विचार-मंथन सत्रों का आयोजन किसी उत्पाद की प्रत्येक विशेषता के महत्व की पहचान करने और विफलता के जोखिम और उत्पादन में अंतिम-उपयोगकर्ताओं पर इसके प्रभाव के आधार पर प्राथमिकता देने के लिए किया जाएगा।

विभिन्न Technical प्रोजेक्ट डॉक्यूमेंट्स ’जैसे कि रिक्वायरमेंट डॉक्यूमेंट, टेक्निकल स्पेसिफिकेशन डॉक्यूमेंट्स, आर्किटेक्चर एंड डिजाइन डॉक्यूमेंट्स, बिजनेस प्रोसेस डॉक्यूमेंट, यूसेज केस डॉक्यूमेंट आदि मंथन सत्र के लिए इनपुट बन जाएंगे।

उत्पाद के बारे में स्टेकहोल्डर का ज्ञान और बाजार में मौजूदा उत्पाद भी चर्चा का एक इनपुट कारक होगा।

इनपुट के कुछ अन्य स्रोतों में भी शामिल हो सकते हैं,

• सबसे अधिक उपयोग की जाने वाली कार्यक्षमता पर इनपुट इकट्ठा करने के लिए।
• एक डोमेन विशेषज्ञ से परामर्श करने से इनपुट।
• उत्पाद के पिछले संस्करण या बाजार में इसी तरह के उत्पाद से डेटा।

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

'जोखिम होने की संभावना' के कारण हो सकता है:

• उत्पाद विकास टीम द्वारा सुविधा की खराब समझ।
• बेहतर वास्तुकला और डिजाइन।
• डिजाइन करने के लिए अपर्याप्त समय।
• टीम की अक्षमता।
• अपर्याप्त संसाधन - लोग, उपकरण और तकनीक।

'जोखिम का प्रभाव' उपयोगकर्ताओं और व्यापार में विफलता का प्रभाव होता है यदि ऐसा होता है। प्रभाव हो सकता है,

• लागत प्रभाव, जिसके परिणामस्वरूप नुकसान हुआ।
• व्यापार प्रभाव व्यापार खोने या बाजार में हिस्सेदारी खोने के परिणामस्वरूप, कानून की कार्यवाही, लाइसेंस की हानि।
• गुणवत्ता प्रभाव, घटिया या अक्षम उत्पाद के परिणामस्वरूप।
• खराब उपयोगकर्ता अनुभव, जिसके परिणामस्वरूप असंतुष्ट और ग्राहक की हानि होती है।

किसी विशेषता या उत्पाद के जोखिम का आकलन करने का फोकस क्षेत्र हो सकता है,

• कार्यक्षमता की व्यावसायिक आलोचना का क्षेत्र।
• अधिकांश उपयोग की जाने वाली विशेषताएं और महत्वपूर्ण कार्यक्षमता।
• दोष प्रवण क्षेत्रों
• सुरक्षा और सुरक्षा प्रभाव को कार्यात्मकता।
• परिसर डिजाइन और वास्तुकला का क्षेत्र।
• पिछले संस्करणों से किए गए परिवर्तन।

जोखिम विश्लेषण पद्धति

आइए अब 'जोखिम-आधारित परीक्षण पद्धति' को विस्तार से समझते हैं।

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

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

जोखिम विश्लेषण का मुख्य उद्देश्य के बीच अंतर करना है 'उच्च मूल्य' उत्पाद सुविधाएँ, कार्यक्षमताओं, आवश्यकताओं जैसे आइटम प्रयोक्ता कहानियां , और परीक्षण के मामले, और and कम मूल्य' वे और इसलिए बाद में value उच्च मूल्य ’टेस्ट मामलों पर अधिक ध्यान केंद्रित करने के लिए, value कम मूल्य’ टेस्ट मामलों पर कम ध्यान केंद्रित करके। यह जोखिम-आधारित परीक्षण शुरू करने से पहले जोखिम विश्लेषण का प्रारंभिक चरण है।

उच्च मूल्य और निम्न मूल्य में परीक्षण के मामलों को वर्गीकृत या समूहीकृत करने का मुख्य कार्य और इनमें से प्रत्येक परीक्षण मामलों को प्राथमिकता मूल्य प्रदान करना निम्नलिखित चरणों में शामिल है:

चरण # 1) 3X3 ग्रिड का उपयोग करना

जोखिम विश्लेषण 3X3 ग्रिड का उपयोग करके किया जाता है, जहां प्रत्येक कार्यक्षमता, गैर-कार्यक्षमता और इसके संबंधित परीक्षण मामलों का मूल्यांकन इसके हितधारकों की एक टीम द्वारा किया जाता है aसंभावनाविफलता 'और' विफलता का प्रभाव '।

उत्पादन में प्रत्येक कार्यक्षमता की विफलता की संभावना आम तौर पर ’तकनीकी विशेषज्ञों’ के एक समूह द्वारा एक्सेस की जाती है और ग्रिड के ऊर्ध्वाधर अक्ष के साथ as संभवतः विफल, काफी संभावना और संभावना नहीं ’के रूप में वर्गीकृत की जाती है।

वेब सेवाएं प्रश्न और उत्तर का साक्षात्कार करती हैं

इसी प्रकार, उत्पादन में इन सुविधाओं और कार्यक्षमता में failure विफलता का प्रभाव ’अंतिम ग्राहक द्वारा अनुभव किया जाता है, यदि परीक्षण नहीं किया जाता है तो समूह द्वारा मूल्यांकन किया जाता है ' व्यवसाय विशेषज्ञ ”और ग्रिड के क्षैतिज अक्ष के साथ ists माइनर, दर्शनीय और रुकावट’ श्रेणियों के तहत वर्गीकृत किए गए हैं।

चरण # 2) विफलता की संभावना और प्रभाव

सभी टेस्ट मामलों को विफलता की संभावना और विफलता के प्रभाव के पहचाने गए मूल्यों के आधार पर 3 एक्स 3 ग्रिड के क्वाडंटेंट्स में तैनात किया जाता है जो नीचे दिए गए चित्र में डॉट्स के रूप में दिखाए गए हैं।

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

चरण # 3) प्राथमिकता ग्रिड का परीक्षण करना

ग्रिड में परीक्षण मामलों की उपरोक्त स्थिति के आधार पर, परीक्षणों को प्राथमिकता दी जाती है और प्राथमिकताओं 1,2,3,4 और 5 के साथ लेबल किया जाता है और उनमें से प्रत्येक के खिलाफ चिह्नित किया जाता है। सबसे महत्वपूर्ण परीक्षण 1 में तैनात हैं^{अनुसूचित जनजाति}ग्रिड जिन्हें प्राथमिकता 1 के साथ सौंपा गया है और इसी तरह कम महत्वपूर्ण लोगों को 2, 3, 4 और 5 के रूप में रैंक किया गया है।

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

चरण # 4) परीक्षण का विवरण

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

रैंकिंग 1 के साथ उच्च प्राथमिकता वाले परीक्षण Th मोर थोरोली ’परीक्षण किए गए हैं और तदनुसार, विशेषज्ञों को इन उच्च महत्वपूर्ण विशेषताओं और इसके संबंधित परीक्षण मामलों का परीक्षण करने के लिए तैनात किया गया है। इसी तरह से प्राथमिकता वाले मामलों का परीक्षण 2, 3, और 4. प्राथमिकता के 5 विकल्पों को डी-स्कोप करने का निर्णय और उपलब्ध समय और संसाधनों के आधार पर परीक्षण किए जा सकते हैं।

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

आरबीटी एजाइल और देवओप्स के लिए प्रासंगिक कैसे है?

अब, किसी विशेष सुविधा के 'जोखिम के जोखिम' और लाइव में 'ग्राहक पर प्रभाव' के आधार पर परीक्षणों के प्राथमिकता के आधार पर परीक्षण करने के जोखिम-आधारित परीक्षण दृष्टिकोण को समझने के बाद, जाहिर है कि कोई भी प्रश्न उठाएगा चुस्त और DevOps प्रथाओं में जोखिम आधारित परीक्षण दृष्टिकोण की प्रासंगिकता।

‘सब कुछ स्वचालित करें’, Everything टेस्ट एवरीथिंग ’, u टेस्ट कंटीन्यूअसली’, Rep टेस्ट रिपीटेडली ’इन प्रथाओं की प्रमुख अवधारणाएं हैं।

हर बार, जब कोड में कोई परिवर्तन होता है या कोई रिलीज़ होता है, तो सभी डिज़ाइन किए गए परीक्षण स्वचालित के माध्यम से चलाए जाते हैं निरंतर एकीकरण (CI) / सतत वितरण (सीडी) पाइपलाइन जल्दी और बार-बार, उनकी प्राथमिकता के बावजूद।

फिर RBT और DevOps के बीच क्या संबंध है? आरबीटी कहाँ फिट होगा और एजाइल और देवो में प्रासंगिक हो जाएगा ???

# 1) हां, जैसा कि मैंने पहले कहा, ऐसा नहीं है कि प्रत्येक उद्योग और प्रत्येक उत्पाद के पास अपने परीक्षण निष्पादन के लिए 100% स्वचालन कवरेज है। इसलिए, अगर सभी टीम को मैन्युअल परीक्षण मामलों की पसंद से परीक्षण निष्पादन के लिए प्राथमिकता का विकल्प बनाना है और अन्य गतिविधियों के लिए परीक्षण संसाधनों की ऊर्जा और प्रयास को छोड़ना चाहते हैं, तो आरबीटी सबसे अच्छा विकल्प है।

जोखिम-आधारित दृष्टिकोण उच्च प्राथमिकता वाले स्वचालित परीक्षण चलाने और जल्द से जल्द परीक्षण के लिए एक बेहतर शर्त है।

#दो) आवश्यकताओं का विश्लेषण करने और उत्पादों के संभावित जोखिमों और विशेषताओं की अग्रिम रिपोर्ट प्रदान करने के लिए क्यूए टीम आरबीटी दृष्टिकोण को अधिक प्रभावी ढंग से अपना सकती है ताकि कार्यक्रम को कम करने के लिए कार्यक्रम टीम द्वारा उचित कार्रवाई की जा सके।

# 3) आरबीटी दृष्टिकोण का उपयोग उच्च जोखिम के आधार पर परीक्षण के मामलों और परिदृश्यों को तैयार करने में प्रभावी ढंग से किया जा सकता है ताकि उच्च जोखिम वाले सुविधाओं और कार्यात्मकताओं की ओर अधिक ध्यान दिया जा सके।

# 4) 'हाई रिस्क' क्षेत्रों की पहचान करना QA टीम को 'हाई स्किल्ड टेस्टर्स' का उपयोग करके 'अधिक अच्छी तरह से' का परीक्षण करने के लिए उन क्षेत्रों पर अपने परीक्षण प्रयास को केंद्रित करने में सक्षम बनाता है।

# 5) 'फेल फास्ट ’, जैसा कि हम सभी जानते हैं कि' एजाइल’ और ps DevOps ’की अवधारणा है, जिसके लिए RBT दृष्टिकोण सॉफ्टवेयर में in उच्च जोखिम’ वाले क्षेत्रों की पहचान करने, दोषों को जल्दी पहचानने और उन्हें तेजी से और असफल होने देने में मदद करता है। पहले और टीम को इसे ठीक करने दें।

# 6) Agile / DevOps का अंतिम लक्ष्य ’ग्राहक फ़ोकस’ है और इसलिए RBT दृष्टिकोण QA को केवल दोष खोजने की तुलना में ग्राहक अनुभव पर ध्यान केंद्रित करने में सक्षम बनाता है।

जोखिम-आधारित परीक्षण दृष्टिकोण के लाभ

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

हम जोखिम-आधारित परीक्षण के लाभों को समेकित और सूचीबद्ध कर सकते हैं:

• परीक्षण संसाधनों के अधिक कुशल और अनुकूलित उपयोग में मदद करता है।
• क्यूए काम, परीक्षण, परीक्षण डिजाइन और विकास, और प्राथमिकता के आधार पर परीक्षण तैयारी गतिविधियों को आसान बनाने में मदद करता है।
• उच्च फोकस क्षेत्रों की ओर प्रमुख संसाधनों को आवंटित करके क्यूए संसाधनों का बेहतर प्रबंधन करने में मदद करता है।
• यह संसाधनों के प्रभावी उपयोग में मदद करता है और परियोजना में बेहतर चीजों पर अपने समय और ऊर्जा को परिवर्तित करता है।
• जोखिम मूल्यांकन और अस्थिर और उच्च जोखिम वाले क्षेत्रों की पहचान के आधार पर परीक्षण प्रयासों की योजना बनाने में क्यूए टीम की मदद करता है।
• यह टीम को महत्व के आधार पर आयोजित किए जाने वाले परीक्षणों का अनुकूलन करने में मदद करता है और इसलिए हितधारकों के साथ कम-मूल्य परीक्षण में कमी करता है।
• कुल मिलाकर यह अनुकूलित और कम परीक्षण गतिविधियों के माध्यम से लागत में कमी में मदद करता है।
• RBT दृष्टिकोण QA टीम को पहले उच्च जोखिम वाले क्षेत्रों का परीक्षण करने में सक्षम बनाता है और उत्पाद को ’फेल फास्ट’ और तेजी से ठीक करने की अनुमति देता है।
• RBT दृष्टिकोण helps में स्पष्टता लाने में मदद करता है टेस्ट कवरेज ' और। टेस्ट स्कोप ’हितधारकों के पूरे समूह के लिए।
• टीम उच्च-जोखिम वाले क्षेत्रों पर अपना ध्यान बढ़ा सकती है और कम-जोखिम वाले क्षेत्र पर कम ध्यान केंद्रित कर सकती है।
• आरबीटी टीम को उत्पाद जोखिमों के लिए शमन के सबसे प्रभावी तरीके के कार्यान्वयन पर अग्रिम रूप से अच्छी तरह से निर्णय लेने की अनुमति देता है।
• आरबीटी मितलीकरण के अनुचित कार्यान्वयन के प्रभाव से बचने में मदद करता है।
• जोखिम-आधारित परीक्षण टीम को या तो जोखिम को कम करने या आकस्मिकता के लिए योजना बनाने या विफलता को दूर करने या लाइव में जोखिम होने पर इसके प्रभाव को कम करने के लिए किसी भी स्थिति में स्थिति में लाने के लिए उचित कार्रवाई करने की अनुमति देता है।
• आरबीटी रिलीज में अवशिष्ट जोखिम को कम करने में मदद करता है।
• यह उत्पादन में कम लागत वाले दोषों के माध्यम से 'बेहतर गुणवत्ता' प्राप्त करने में मदद करता है।
• अंततः 'बेहतर ग्राहक अनुभव' और 'संतुष्ट ग्राहक' में मदद करता है।

अगला, हम सीखेंगे कि सॉफ्टवेयर परीक्षण जीवन चक्र के परीक्षण योजना और परीक्षण निष्पादन चरणों में जोखिम का प्रबंधन कैसे करें।

परीक्षण योजना के दौरान जोखिम प्रबंधन

टेस्ट प्लानिंग चरण के दौरान जोखिम कैसे प्रबंधित करें:

जीवन जोखिमों से भरा है, और ऐसा ही एक सॉफ्टवेयर प्रोजेक्ट है। कभी भी कुछ भी गलत हो सकता है। हम हमेशा चीजों को सही बनाने के लिए अपने पैर की उंगलियों पर होते हैं - लेकिन क्या यह सुनिश्चित करने के बारे में कि कुछ भी गलत नहीं होता है और जब यह हमें पता है कि वास्तव में क्या करना है? जोखिम प्रबंधन दर्ज करें - यह एक सॉफ्टवेयर परीक्षण परियोजना का एक हिस्सा है जो हमें जोखिमों को रोकने, समझने, खोजने और प्राप्त करने के लिए तैयार करता है।

एक जोखिम केवल एक समस्या है जो होने की संभावना है और जब ऐसा होता है, तो यह नुकसान का कारण होगा।

नुकसान कुछ भी हो सकता है- पैसा, समय, प्रयास या गुणवत्ता में समझौता। नुकसान कभी अच्छा नहीं होता। हम इसे कितना भी स्पिन क्यों न दें, यह सकारात्मक नहीं है- और कभी भी नहीं होगा। इसलिये जोखिम प्रबंधन यह सुनिश्चित करने के लिए कि हम जोखिमों से निपटने और नुकसान को रोकने / कम करने के लिए सॉफ़्टवेयर प्रोजेक्ट्स का एक अभिन्न हिस्सा हैं।

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

जोखिम प्रबंधन प्रक्रिया दो बार होती है, इस दौरान:

1. परीक्षण योजना
2. टेस्ट केस डिजाइन (अंत) या कभी-कभी टेस्ट निष्पादन चरण में

यह 1 के मामले में अनिवार्य है, लेकिन केस 2 के साथ यह 'जरूरत-आधार' की स्थिति से अधिक है।

दो-भाग लेख श्रृंखला:

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

यह खंड “परीक्षण योजना के दौरान जोखिम प्रबंधन”।

जोखिम प्रबंधन प्रक्रिया

जोखिम प्रबंधन के लिए सामान्य प्रक्रिया में 3 महत्वपूर्ण चरण शामिल हैं:

1. जोखिम की पहचान
2. जोखिम प्रभाव विश्लेषण
3. जोखिम से राहत

परीक्षण जोखिम और शमन परीक्षा:

(1) जोखिम पहचान

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

इस कदम का मुख्य परिणाम जोखिमों की एक सूची है।

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

साथ ही, परीक्षण योजना के चरण के दौरान जिन जोखिमों की पहचान की जाती है, वे उन्मुखीकरण में अधिक 'प्रबंधकीय' हैं, जिसका अर्थ है, हम किसी भी चीज को देखने जा रहे हैं जो QA परियोजना के कार्यक्रम, प्रयास, बजट, बुनियादी ढांचे में बदलाव आदि को प्रभावित कर सकती है। ऑटो नहीं, लेकिन क्यूए चरण जिस तरह से आगे बढ़ेगा।

टेस्ट प्लानिंग के दौरान जोखिम: जोखिम-आधारित परीक्षण उदाहरण

निम्नलिखित उन जोखिमों की एक नमूना सूची है, जिन्हें परीक्षण योजना चरण के दौरान सूचीबद्ध किया जा सकता है। कृपया ध्यान दें, कि ऑटो और इसकी कार्यक्षमता यहाँ ध्यान केंद्रित नहीं है।

1. परीक्षण अनुसूची तंग है। यदि डिज़ाइन कार्यों के कारण परीक्षण की शुरुआत में देरी हो रही है, तो परीक्षण को UAT निर्धारित प्रारंभ तिथि से आगे नहीं बढ़ाया जा सकता है।
2. पर्याप्त संसाधन नहीं, संसाधन बहुत देर से चालू होते हैं (प्रक्रिया में लगभग 15 दिन लगते हैं)
3. चक्र के देर से चरण में या देर से चक्र में दोष पाए जाते हैं; देर से खोजे गए दोष स्पष्ट रूप से स्पष्ट विनिर्देशों के कारण होते हैं और समय-समय पर हल करने के लिए होते हैं।
4. स्कोप पूरी तरह से परिभाषित नहीं है
5. प्राकृतिक आपदा
6. स्वतंत्र की अनुपलब्धता परीक्षण का वातावरण और पहुँच क्षमता
7. नए मुद्दों के कारण विलंबित परीक्षण

इस बिंदु पर, आप उपलब्ध समय की मात्रा के आधार पर जितना चाहे उतना अच्छा विकल्प चुन सकते हैं।

एक बार, सभी जोखिम सूचीबद्ध हैं, हम जोखिम मूल्यांकन / जोखिम प्रभाव विश्लेषण के लिए प्रगति करते हैं।

# 2) जोखिम मूल्यांकन / जोखिम प्रभाव विश्लेषण

क्या आपका जोखिम विश्लेषण कुछ इस तरह है? :)

सॉफ्टवेयर परीक्षण में जोखिम विश्लेषण : इस चरण में सभी जोखिमों को निर्धारित और प्राथमिकता दी गई है। हर जोखिम की संभावना (घटना होने की संभावना) और प्रभाव (नुकसान की मात्रा जो इस जोखिम के कारण होती है जब यह व्यवस्थित होता है)।

उच्च मध्यम निम्न , मूल्यों को प्रत्येक जोखिम की संभावना और प्रभाव दोनों को सौंपा गया है। 'उच्च' संभावना और 'उच्च' प्रभाव वाले जोखिमों पर पहले ध्यान दिया जाता है और फिर आदेश का पालन किया जाता है।

जोखिम प्रभाव विश्लेषण तालिका:

इन चरणों के बाद, ऊपर सूचीबद्ध जोखिमों के लिए जोखिम प्रभाव विश्लेषण तालिका कुछ इस तरह दिखाई देगी (सभी मान काल्पनिक हैं और केवल अन्य उद्देश्यों के लिए हैं:

# 3) जोखिम शमन

इस जोखिम-आधारित परीक्षण (आरबीटी) प्रक्रिया का अंतिम चरण इन स्थितियों में से प्रत्येक को कैसे प्रबंधित करना है, इसकी योजना के लिए समाधान खोजना है। ये योजनाएं कंपनी से कंपनी, परियोजना से परियोजना और यहां तक ​​कि व्यक्ति से व्यक्ति तक भिन्न हो सकती हैं।

जोखिम शमन तकनीक:

इस चरण के पूर्ण होने पर जोखिम तालिका में रूपांतरित होने का एक उदाहरण इस प्रकार है:

नोट करने के लिए कुछ बिंदु:

1. जितनी जल्दी जोखिम प्रबंधन एक क्यूए परियोजना नियोजन चरण में शुरू होता है, उतना बेहतर होता है।
2. सभी 3 चरणों में, जोखिम की पहचान सबसे महत्वपूर्ण है । यदि कुछ भी सूचीबद्ध नहीं है और आगे के चरणों के लिए विचार किया जाता है, तो जोखिम अनहैंड हो जाता है।
3. इस गतिविधि के लिए एक आदर्श समय सीमा खोजने की कोशिश करें। याद रखें, बहुत ज्यादा प्लानिंग करने से बहुत कम समय निकलता है।
4. इसके अलावा, जोखिम प्रबंधन प्रक्रिया के बाद, यदि कोई नई स्थिति आती है, तो जोखिम प्रबंधन योजना को बदल दिया जा सकता है या सबसे मौजूदा स्थिति को प्रतिबिंबित करने के लिए अद्यतन किया जा सकता है।
5. ऐतिहासिक डेटा इस प्रक्रिया की सफलता के लिए बहुत उपयोगी हो सकता है।

निष्कर्ष

यह हमें टेस्ट प्लानिंग चरण में जोखिम प्रबंधन के अंत में लाता है। भले ही अंतर्निहित चरण और सिद्धांत समान हों, लेकिन परीक्षण डिजाइनिंग / निष्पादन चरण में होने पर जोखिम प्रबंधन प्रक्रिया ऑटो के प्रति अधिक केंद्रित होती है।

हमारे अगले भाग में, हम कवर करेंगे - परीक्षण निष्पादन चरण में जोखिम प्रबंधन।

परीक्षण निष्पादन चरण में जोखिम प्रबंधन (उदाहरण के साथ)

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

टेस्ट डिजाइनिंग या टेस्ट निष्पादन चरण में जोखिम का प्रबंधन कैसे करें:

का एक दूसरा रूप है जोखिम प्रबंधन (कभी कभी के रूप में भी जाना जाता है, जोखिम आधारित परीक्षण ) जो स्थिति के आधार पर टेस्ट डिजाइनिंग या टेस्ट निष्पादन चरण के दौरान होता है। अब हम किस स्थिति की बात कर रहे हैं? आइए हम पहले यह समझने की कोशिश करें।

हम सभी जानते हैं कि हमारा परीक्षण कार्य प्रतिक्रियाशील है। कोई आवश्यकता (या गुंजाइश परिभाषित नहीं), हम व्यवहार्यता विश्लेषण नहीं कर सकते हैं और परीक्षण परिदृश्य लिख सकते हैं या परीक्षण गतिविधियों के लिए योजना बना सकते हैं।

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

जोखिम प्रबंधन - ऑटो पर ध्यान देने के साथ

आइए इसे एक उदाहरण से समझते हैं:

उदाहरण के साथ प्रणाली विकास जीवन चक्र चरण

यदि परीक्षण दिनांक 1 जनवरी से शुरू होना था^{अनुसूचित जनजाति}और 14 जनवरी तक जाना था^वें- जब परीक्षण किया जाता है, तो उत्पाद की गो-लाइव तिथि आमतौर पर तुरंत तय की जाती है। आइए बताते हैं- 15 जनवरी^वेंसादगी के लिए। अब, सही दुनिया में चीजें ठीक उसी तरह की होती हैं जैसी कि योजना बनाई जाती है। लेकिन हम सभी वास्तविकता जानते हैं।

इस मामले में, मान लें कि किसी कारण से, परीक्षण 7 जनवरी तक शुरू नहीं हुआ^वें, जिसका मतलब है कि हमने अपना आधा परीक्षण समय गंवा दिया। लेकिन हमें उत्पाद का पूरी तरह से परीक्षण करने के लिए 14 दिनों की आवश्यकता है। हम 7 दिन तक गो-लाइव डेट को आगे बढ़ा सकते थे- हालाँकि; यह आमतौर पर एक विकल्प नहीं है। क्योंकि उत्पाद को निश्चित तिथि पर बाजार में हिट करने का वादा किया जाता है और कोई भी देरी व्यवसाय के लिए अच्छी नहीं होती है।

इसलिए, आमतौर पर, हम परीक्षण टीमों को देरी को अवशोषित करना है, किसी तरह क्षतिपूर्ति करना है, उपलब्ध समय के साथ काम करना है और सुनिश्चित करें कि उत्पाद का अच्छी तरह से परीक्षण किया गया है। कठिन काम है, क्या यह नहीं है?

यह वह जगह है जहां जोखिम प्रबंधन प्रक्रिया को फिर से नियोजित किया जाता है।

• अब अगर देरी समय से पहले होने का अनुमान है परीक्षण शुरू होने से पहले- प्रक्रिया डिजाइनिंग चरण में होती है।
• अगर देरी एक के दौरान होता है परीक्षण निष्पादन चरण यह सामान्य रूप से शुरू हुआ- परीक्षण निष्पादन चरण के दौरान प्रक्रिया का पालन किया जाता है।
• चरण और विधि समान हैं कोई फर्क नहीं पड़ता कि यह किस चरण में होता है।

प्रक्रिया क्या है?

जोखिम प्रबंधन यह निर्धारित करने के लिए होता है कि ऑटो (एप्लिकेशन अंडर टेस्ट) के किन क्षेत्रों पर अधिकतम ध्यान देने की आवश्यकता है। ये आम तौर पर कार्यात्मक क्षेत्र (मॉड्यूल या घटक) हैं जो अंतिम उत्पाद की सफलता के लिए महत्वपूर्ण हैं और विफलता के लिए सबसे अधिक प्रवण हैं।

ये भी पढ़ें=> विफलता मोड और प्रभाव विश्लेषण (FMEA) एक जोखिम प्रबंधन तकनीक है

इसे कौन करता है?

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

कैसे जोखिम मामलों का परीक्षण होता है?

चरण 1) जोखिम की पहचान

ऑटो के सभी कार्यात्मक क्षेत्रों की पहचान करें। इसमें बस एक सूची बनाना शामिल होगा।

चरण 2) जोखिम आकलन

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

हर जोखिम की संभावना (घटना होने की संभावना) और प्रभाव (नुकसान की मात्रा जो इस जोखिम के होने पर होती है)।

रेटिंग्स निर्दिष्ट करने के लिए विशिष्ट विधि है। उदाहरण के लिए, संभावना 1 से 5. मान ले सकती है। घटना घटने की संभावना कम होने की संभावना है (सभी में होने की संभावना नहीं है) और 5 उच्च होने (सबसे निश्चित रूप से होगा)।

इसी तरह, इंपैक्ट को भी 1-5 रेटिंग दी जा सकती है। 1 कम प्रभाव वाला होना (भले ही यह जोखिम कम हो, नुकसान न्यूनतम है) और 5 उच्च प्रभाव (जब होता है भारी नुकसान)।

चरण 3)

एक टेबल प्रारूप बनाएं और सभी टीम प्रतिनिधि- देव, बीए, क्लाइंट, पीएम, क्यूए और किसी अन्य व्यक्ति के लिए परिचालित करें।

चरण 4)

प्रत्येक टीम को संभावना और प्रभाव के लिए उनकी रेटिंग के आधार पर मूल्यों को भरने का निर्देश दें।

चूंकि संभाव्यता और प्रभाव मूल्य संख्यात्मक हैं, इसलिए यह 'जोखिम कारक' मूल्य की गणना को आसान बना देगा।

जोखिम कारक = संभावना X प्रभाव। जोखिम कारक जितना अधिक होगा, समस्या उतनी ही गंभीर होगी।

एक उदाहरण:

कृपया ध्यान दें कि इस बिंदु पर, यह केवल एक टीम की रेटिंग का परिणाम है। एक परियोजना के लिए जहां 5 अलग-अलग टीमें शामिल होती हैं, क्यूए टीम 5 अलग-अलग तालिकाओं के साथ समाप्त होती है।

चरण # 5)

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

जितना अधिक जोखिम कारक, उतना अधिक उस मॉड्यूल का परीक्षण करना होगा।

इसलिए, मॉड्यूल 5 और 2 व्यवसाय की सफलता के लिए सबसे महत्वपूर्ण हैं। सभी टीमों के साथ परिणाम साझा करें।

चरण # 6)

जोखिम शमन योजना : अब, यह वह चरण है जो प्रोजेक्ट से प्रोजेक्ट में बदलता है। हमने पाया है कि मॉड्यूल 5 और 2 ऐसे हैं, जिन्हें सबसे अधिक ध्यान केंद्रित करने की आवश्यकता है।

उदाहरणयोजना की जा सकती है:

1. मॉड्यूल 5 और 2 का पूरी तरह से परीक्षण किया जाएगा ताकि यह सुनिश्चित हो सके कि उनसे संबंधित सभी परीक्षण मामलों का परीक्षण किया गया है। अन्य मॉड्यूलों का अन्वेषणात्मक आधार पर परीक्षण किया जाएगा।
2. मॉड्यूल 5 और 2 का परीक्षण पहले किया जा रहा है और फिर उपलब्ध समय के आधार पर दूसरों का ध्यान रखा जाएगा।

एक बार एक योजना बन जाने के बाद, सभी टीम एक समझौते पर पहुंचती हैं और जोखिम-कारक को ध्यान में रखते हुए उत्पाद का परीक्षण करने के लिए इसका पालन करती हैं।

इतना ही!

नोट करने के लिए कुछ महत्वपूर्ण बिंदु:

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

निष्कर्ष

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

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

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

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

पी। एस। क्यूए और परीक्षण शब्द पूरे दस्तावेज़ में परस्पर उपयोग किए गए हैं।

लेखक के बारे में: यह लेख कई एसटीएच टीम सदस्यों द्वारा लिखा गया है - गायत्री सुब्रह्मण्यम और स्वाति एस।

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

क्या जोखिम आधारित परीक्षण आपके लिए चुनौतीपूर्ण था? क्या आपके पास हमारे ट्यूटोरियल में जोड़ने के लिए कोई दिलचस्प तथ्य है? नीचे टिप्पणी अनुभाग में अपने विचार व्यक्त करने के लिए स्वतंत्र महसूस करें !!

=> पूरी टेस्ट प्लान ट्यूटोरियल सीरीज़ के लिए यहां जाएं

अनुशंसित पाठ

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