मेन्यू

दोष प्रबंधन प्रक्रिया: प्रभावी रूप से एक दोष प्रबंधन कैसे करें

  • मुख्य
  • अन्य
  • दोष प्रबंधन प्रक्रिया: प्रभावी रूप से एक दोष प्रबंधन कैसे करें

defect management process

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

दोष प्रबंधन प्रक्रिया का परिचय:

अधिक केंद्रित प्रक्रिया और परीक्षण बाजार में कम बगिया सॉफ्टवेयर की अनुमति देगा।

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

दोष प्रबंधन प्रक्रिया

कैसे खरोंच से स्वचालन परीक्षण शुरू करने के लिए

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

दोष प्रबंधन प्रक्रिया के लक्ष्य (डीएमपी)

नीचे दिए गए इस प्रक्रिया के विभिन्न लक्ष्य हैं:

  • दोष को रोकें
  • जल्दी पता लगाने के
  • प्रभाव कम करें
  • दोष का समाधान
  • प्रक्रिया विकाशन

दोष प्रबंधन प्रक्रिया की खोज करने से पहले, हमें पहले समझें वास्तव में एक दोष या बग क्या है?

दोष प्रबंधन जीवन चक्र

जब कोई प्रणाली वास्तविक व्यावसायिक आवश्यकता के अलावा एक अलग आउटपुट देती है यानी जब वास्तविक या मूल व्यावसायिक आवश्यकता से विचलन होता है तो हम कह सकते हैं कि सिस्टम / सॉफ़्टवेयर में कोई खराबी है।

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

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

उचित रूप से परियोजनाओं को संभालने के लिए, आपको यह जानना होगा कि विकास और रिलीज से कैसे निपटना है, लेकिन इसके साथ ही आपको यह भी पता होना चाहिए कि दोषों को कैसे संभालना है।

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

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

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

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

अग्रिम पठन:

सॉफ्टवेयर परीक्षण में दोष / बग जीवन चक्र क्या है? दोषपूर्ण जीवन चक्र ट्यूटोरियल

ध्यान दें: नीचे चक्र थोड़ा संगठन से दूसरे संगठन में भिन्न होता है।

नीचे का दोष जीवन चक्र सभी संभावित स्थिति को कवर करता है:

दोष जीवन चक्र फ्लोचार्ट

  • जब भी परीक्षण टीम को आवेदन में कोई खामी मिलती है, तो वे इस स्थिति को ' नवीन व ”।
  • जब QA लीड द्वारा एक नए दोष की समीक्षा की जाती है और यदि दोष वैध है, तो दोष की स्थिति 'होगी' खुला हुआ 'और यह विकास टीम को सौंपा जाने के लिए तैयार है।
  • जब QA लीड संबंधित डेवलपर को दोष सौंपता है, तो दोष की स्थिति 'के रूप में चिह्नित की जाएगी निरुपित ”। एक डेवलपर को इस स्तर पर दोष का विश्लेषण और निर्धारण शुरू करना चाहिए।
  • जब डेवलपर को लगता है कि दोष वास्तविक या वैध नहीं है, तो डेवलपर दोष को खारिज कर देता है। दोष की स्थिति 'के रूप में चिह्नित है ठुकरा दिया 'और परीक्षण टीम को वापस सौंपा गया।
  • यदि दोष लॉग को दो बार दोहराया जाता है या रिपोर्ट किए गए दोनों दोषों के समान परिणाम होते हैं और पुन: उत्पन्न करने के लिए चरण होते हैं, तो एक दोष स्थिति 'में बदल जाती है' डुप्लिकेट ”।
  • यदि किसी विशेष दोष को ठीक करने के लिए वर्तमान रिलीज़ में कुछ समस्याएँ या बाधाएँ हैं, तो दोष वर्तमान रिलीज़ के बजाय आगामी रिलीज़ में लिया जाएगा और फिर इसे 'चिह्नित' किया जाएगा स्थगित '' स्थगित ”।
  • जब एक डेवलपर परीक्षण टीम द्वारा 'स्टेप्स टू रिप्रोड्यूस' में वर्णित चरणों द्वारा दोष को पुन: उत्पन्न करने में सक्षम नहीं होता है, तो डेवलपर दोष को 'के रूप में चिह्नित कर सकता है' प्रतिलिपि प्रस्तुत करने योग्य नहीं' । इस चरण में, परीक्षण टीम को एक डेवलपर को विस्तृत प्रजनन चरण प्रदान करना चाहिए।
  • यदि डेवलपर QA द्वारा दोष को पुन: उत्पन्न करने के लिए प्रदान किए जाने वाले चरणों के बारे में स्पष्ट नहीं है, तो वह इसे प्राप्त कर सकता है ' कुछ और जानकारी चाहिये ”। इस मामले में, परीक्षण टीम को विकास टीम को आवश्यक विवरण प्रदान करने की आवश्यकता है।
  • यदि एक दोष पहले से ही ज्ञात है और वर्तमान में उत्पादन वातावरण में मौजूद है तो दोष ' ज्ञात दोष ”।
  • जब कोई डेवलपर आवश्यक परिवर्तन करता है, तो दोष को 'के रूप में चिह्नित किया जाता है' फिक्स्ड ”।
  • डेवलपर अब सत्यापित करने के लिए परीक्षण टीम में दोष पारित करता है, इसलिए डेवलपर स्थिति को 'के रूप में बदलता है' Retest के लिए तैयार है ”।
  • यदि दोष में कोई और समस्या नहीं है और इसे ठीक से सत्यापित किया गया है, तो परीक्षक दोष को ' बंद किया हुआ ”।
  • यदि परीक्षक ने पाया कि दोष को हटाते समय, दोष अभी भी प्रतिलिपि प्रस्तुत करने योग्य है या आंशिक रूप से तय किया गया है, तो दोष 'के रूप में चिह्नित किया जाएगा।' फिर से खोल दी ”। अब डेवलपर को फिर से इस दोष को देखना होगा।

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

दोष प्रबंधन प्रक्रिया

दोष प्रबंधन प्रक्रिया

दोष प्रबंधन प्रक्रिया को नीचे विस्तार से बताया गया है।

(1) दोष निवारण:

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

हालांकि, सभी दोषों को दूर करना संभव नहीं है, लेकिन कम से कम आप दोष के प्रभाव को कम कर सकते हैं और उसी को ठीक करने के लिए लागत कर सकते हैं।

दोष निवारण में शामिल प्रमुख कदम इस प्रकार हैं:

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

# 2) वितरण योग्य बेसलाइन:

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

उदाहरण के लिए, कोडिंग, यूनिट टेस्टिंग और फिर सिस्टम टेस्टिंग के परिदृश्य पर विचार करें। यदि कोई डेवलपर कोडिंग और यूनिट परीक्षण करता है तो परीक्षण टीम द्वारा सिस्टम परीक्षण किया जाता है। यहां कोडिंग और यूनिट टेस्टिंग एक मील का पत्थर है और सिस्टम टेस्टिंग एक और मील का पत्थर है।

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

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

मुफ्त कार्यक्रम यूट्यूब वीडियो डाउनलोड करने के लिए

असल में, डिलिवरेबल्स में परिवर्तन को अंतिम रूप दिया जाता है और सभी संभावित दोषों की पहचान की जाती है और उन्हें ठीक किया जाता है। फिर वही डिलिवरेबल अगले ग्रुप पर जाता है जो इस पर काम करेगा।

# 3) दोष खोज:

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

दोष डिस्कवरी में शामिल कदम इस प्रकार हैं:

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

# 4) दोष समाधान:

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

दोष समाधान में शामिल चरण इस प्रकार हैं:

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

# 5) प्रक्रिया में सुधार:

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

यहां तक ​​कि ये मामूली दोष सीखने की प्रक्रिया को सुधारने और किसी भी दोष की घटनाओं को रोकने का अवसर देते हैं जो भविष्य में सिस्टम की विफलता को प्रभावित कर सकते हैं। सिस्टम पर कम प्रभाव रखने वाले दोष की पहचान एक बड़ी बात नहीं हो सकती है, लेकिन सिस्टम में इस तरह के दोष का होना एक बड़ी बात है।

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

निष्कर्ष

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

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

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

परीक्षण दृष्टिकोण, समीक्षा प्रक्रिया आदि, परियोजना उद्देश्य या संगठनात्मक प्रक्रिया के आधार पर चुनना चाहिए।

आशा है कि दोषपूर्ण प्रबंधन प्रक्रिया पर यह जानकारीपूर्ण लेख आपको बहुत मदद करेगा।

अनुशंसित पाठ

^