एक ही मुद्दे / टिकट में कई दोषों को पोस्ट करने की अनुशंसा क्यों नहीं की जाती है?


26

मुझे यकीन नहीं है कि यह निम्नलिखित वैचारिक प्रश्न पूछने का स्थान है (स्टैकओवरफ़्लो निश्चित रूप से नहीं है)।

मैंने इस प्रश्न को एक बहुविकल्पी परीक्षा (एकल उत्तर) में देखा, जो आईएसटीक्यूबी परीक्षा के समान है :

एक ही मुद्दे / टिकट में कई दोषों की रिपोर्ट करने की अनुशंसा क्यों नहीं की जाती है?

ए। ताकि रिपोर्ट को संक्षिप्त और स्पष्ट रखा जा सके।

ख। क्योंकि डेवलपर्स केवल एक बग को ठीक कर सकते हैं।

सी। क्योंकि परीक्षण समूह के परीक्षकों को उन बगों की मात्रा से मूल्यांकित किया जाता है जो वे पाते हैं।

घ। बग प्रबंधन प्रणाली कई बगों की इस सुविधा का समर्थन नहीं करती है।

मेरा एकमात्र विचार यह है कि aसही उत्तर है।

b- इसे ठीक नहीं किया जा सकता क्योंकि फिक्स-प्रतिक्रिया-हल-बंद को उस मामले से बचना चाहिए। c- जाहिर है गलत।

d - Redmine / Trac प्लगइन्स कई क्षेत्रों का समर्थन करता है।

उत्तर पुस्तिका के अनुसार उत्तर है b

कोई समझा सकता है क्यों? उत्तरों के बारे में राय के साथ टिप्पणियाँ स्वागत योग्य हैं।


यदि यह पूछने के लिए उपयुक्त जगह नहीं है, तो कृपया मुझे बंद / सूचित करने के लिए मतदान करें, मैं बंद कर दूंगा।
आईरिस

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

25
IMHO सही उत्तर है "क्योंकि प्रत्येक मुद्दे का जीवन चक्र या ट्रैकिंग एक अलग हो सकता है, जिसे प्रबंधित करना कठिन हो जाता है यदि आप एक मुद्दे में कई दोषों को रोकते हैं"। और उस का संक्षिप्त रूप है "डेवलपर्स केवल एक बग को ठीक कर सकते हैं"।
डॉक्टर ब्राउन

यदि आप एक ही टिकट में दो दोषों की अनुमति देते हैं, तो तीन, दस, एक सौ क्यों नहीं? सीमा क्या होगी? आखिर में, इश्यू ट्रैकर की बात क्या होगी?
मौविसील

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

जवाबों:


73

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

बग ट्रैकिंग सिस्टम ... बग्स को ट्रैक करने के लिए किया जाता है। बग पर नज़र रखने का अर्थ है:

  1. यह कहते हुए एक रिकॉर्ड बनाना कि एक बग मौजूद हो सकता है, इसे कैसे पुन: उत्पन्न करने के बारे में जानकारी के साथ,

  2. यह पुष्टि करते हुए कि वास्तव में, बग मौजूद है और एक बग है, डिजाइन द्वारा कुछ नहीं,

  3. यह देखते हुए कि बग अब हल हो गया है,

  4. बग को हल करने की पुष्टि की।

एक बहुत ही सरल मॉडल में, 1 और 4 ग्राहक द्वारा किया जाएगा, और 2 और 3 - डेवलपर द्वारा।

निम्नलिखित लॉग की कल्पना करें:

  • दिन 1 [ग्राहक] "उत्पाद विवरण" विंडो में "निकालें" बटन पर दबाते समय, आवेदन लटका रहता है। एप्लिकेशन को पुनरारंभ करने से पता चलता है कि उत्पाद हटाया नहीं गया था। उत्पाद को हटाने के लिए अपेक्षित व्यवहार है।

  • दिन 4 [डेवलपर] <मुद्दा पुन: प्रस्तुत>

  • 5 दिन [डेवलपर] <समस्या 5031> में संशोधन

  • दिन 12 [ग्राहक] <टिकट बंद: मुद्दा हल>

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

जानकारी पाना आसान है । इसकी स्थिति को देखना आसान है (क्या इसे पुन: प्रस्तुत किया गया है? यदि टिकट बंद था, तो क्यों?)। टिकटों को फ़िल्टर करना आसान है (मैं उन टिकटों को प्रदर्शित करना चाहता हूं जो प्लगइन्स के केवल यूआई की चिंता करते हैं, यह देखते हुए कि मैं केवल ऐसे टिकट चाहता हूं जो खुले हैं, एक सप्ताह से अधिक पुराने हैं और हमारे इंटरैक्शन डिजाइनर द्वारा मुझे सौंपा गया है और मध्यम या उच्च प्राथमिकता वाले हैं)।

टिकट को फिर से असाइन करना या मूल रूप से यह निर्धारित करना आसान है कि वह कौन व्यक्ति है जिसे बग का प्रभारी होना चाहिए।

अब निम्नलिखित लॉग की कल्पना करें:

  • दिन 1 [ग्राहक] जब मैं "उत्पाद विवरण" विंडो में "निकालें" बटन दबाता हूं, तो एप्लिकेशन लटका रहता है। इसके अलावा, बाएं पैनल का पृष्ठभूमि का रंग गहरा नीला है, जबकि यह बैंगनी होना चाहिए। मैंने यह भी नोट किया कि "उत्पाद विवरण" विंडो के पाठ का जर्मन में अच्छी तरह से अनुवाद नहीं किया गया है; क्या यह अपेक्षित है? अंतिम अनुवाद कब उपलब्ध होगा? BTW, क्या आपको "प्रकाशित उत्पाद" कार्रवाई के लिए भेजा गया नया आइकन मिला है? मैं इसे "सिंक डेटा" विंडो में नहीं देखता।

  • दिन 6 [डेवलपर] मैंने रंग को बैंगनी में बदल दिया।

  • दिन 7 [डेवलपर] हाँ, यह सामान्य है कि जर्मन में अनुवाद अधूरा है।

  • दिन 8 [ग्राहक] जर्मन के लिए ठीक है। इतालवी के बारे में क्या? लूसिया ने दो दिन पहले आपको XML फाइल भेजी थी।

  • दिन 9 [डेवलपर] यह अब ठीक है।

  • दिन 10 [ग्राहक] "निकालें" बटन के लिए ठीक है? मेरे कंप्यूटर पर अजीब बात है, यह अभी भी लटका हुआ है।

  • दिन 11 [डेवलपर] नहीं, मैं कहना चाहता था कि यह इतालवी अनुवाद के लिए ठीक है।

  • दिन 12 [ग्राहक] मैं देखता हूं। धन्यवाद। लेकिन रंग के साथ एक समस्या है। आपने इसे गहरे बैंगनी में बदल दिया, लेकिन यह मुख्य खिड़की पर शीर्ष पैनल की तरह हल्का बैंगनी होना चाहिए।

  • दिन 13 [डेवलपर] मैंने आइकन अपडेट किया।

  • 14 दिन [ग्राहक] आइकन? क्या आइकन?

  • 15 दिन [डेवलपर] आइकन आप मुझे अद्यतन करने के लिए कहा।

  • दिन 16 [ग्राहक] मैंने आपसे कभी किसी आइकन को अपडेट करने के लिए नहीं कहा।

  • दिन 17 [डेवलपर] बेशक आप से पूछा। इस टिकट को देखें। आपने लिखा है कि प्रकाशित उत्पाद आइकन को अपडेट किया जाना चाहिए। मेंने यह किया है।

  • 100 दिन [ग्राहक] तो, लॉग में प्रविष्टियों के बारे में क्या?

  • दिन 101 [डेवलपर] मुझे पता नहीं है कि आप किस बारे में बात कर रहे हैं। यह इस टिकट में भी नहीं है, लेकिन 6199 में। मैं इसे हल कर रहा हूं। <टिकट बंद: मुद्दा हल>

  • दिन 102 [ग्राहक] इसे फिर से खोलने के लिए क्षमा करें, लेकिन समस्या हल नहीं हुई है। मैं लॉग में प्रविष्टियों के बारे में बात कर रहा हूं: मैंने पिछले सप्ताह आपको बताया था कि जब यूनिकोड वर्ण होते हैं तो पाठ कभी-कभी अमान्य होता है। क्या तुम्हें याद है? <टिकट फिर से खोला>

  • दिन 103 [डेवलपर] मुझे अस्पष्ट रूप से ऐसा कुछ याद है, लेकिन इस टिकट के अंतिम तीन पृष्ठों को खोजने के बाद, मुझे कोई निशान नहीं मिला। क्या आप फिर से लिख सकते हैं कि समस्या क्या थी?

  • दिन 460 [डेवलपर] मैंने नेटवर्क के माध्यम से एन्क्रिप्ट की गई फ़ाइलों के बारे में जो कुछ भी कहा है उसका एक ट्रेस तलाशने में दो घंटे बिताए। मुझे यकीन नहीं है कि मुझे सटीक अनुरोध मिल सकता है।

  • दिन 460 [ग्राहक] आप लोगों को वास्तव में अधिक संगठित होना चाहिए। मैंने पिछले दो हफ्तों से आपको इस मुद्दे के बारे में चार बार सूचित किया। आप सब कुछ क्यों भूल रहे हैं?

यह किस बारे में है? इसे 43 बार हल किया गया और 43 बार फिर से खोला गया। क्या इसका मतलब यह है कि डेवलपर इतना बेवकूफ है कि वह 460 दिनों तक एक ही मुद्दे को हल नहीं कर सकता है? आह, नहीं, रुको, इस टिकट को इस बीच 11 डेवलपर्स को सौंपा गया था। क्या बात है? किसी विशिष्ट मुद्दे की खोज कैसे करें? यह वास्तव में वैनेसा को सौंपा गया है, लेकिन उसके पांच सहयोगियों को इस टिकट में ग्यारह मुद्दों में से सात से चिंतित हैं। टिकट कब बंद होना चाहिए? क्या यह तब होता है जब आधे मुद्दे हल हो जाते हैं? या शायद ग्यारह में से दस?

नोट: आप मान सकते हैं कि इस तरह के लॉग मौजूद नहीं हैं। मेरा विश्वास करो, मैंने लोगों को एक से अधिक बार देखा है।


लंबे उत्तर के लिए धन्यवाद, मैं ट्रैकिंग प्रणाली के महत्व के बारे में आपके बिंदुओं से सहमत हूं।
आइरिस

आप क्या जवाब देंगे?
आइरिस

3
@ ओफिरिस: ए और बी
आर्सेनी मूरज़ेंको

मैं प्रस्तुत करता हूं कि इस तरह के लॉग के पीछे की वास्तविक समस्या उन उपयोगकर्ताओं की है जो रवैया लेते हैं, "मुझे वास्तव में एक डेवलपर का ध्यान है, मैं उन्हें वह सब कुछ ठीक करने के लिए प्राप्त करूंगा, जिसे हमें तय करने की आवश्यकता है!" जो एक व्यवसाय का एक लक्षण है जो आंतरिक आवश्यकताओं को प्राथमिकता देने के मूल्य को छूट देता है।
btilly

1
@btilly: मुझे लगता है कि यह यह रवैया नहीं है, बल्कि यह बुरी तरह से संगठित होने का तथ्य है, और इसके अलावा एक बुरी तरह से डिज़ाइन किया गया बग ट्रैकिंग सिस्टम है (मैं UX डिज़ाइन के बारे में बात कर रहा हूं)। यदि अतिरिक्त टिकट बनाने के लिए दस क्लिक की आवश्यकता होती है, तो अधिकांश ग्राहकों को एक ही टिकट में कई मुद्दे डालकर हर कीमत पर इससे बचने की कोशिश करते हुए देखना आश्चर्यजनक नहीं होगा।
आर्सेनी मूरज़ेंको

12

बस अपने बयान पर टिप्पणी करने के लिए:

इसे ठीक नहीं किया जा सकता क्योंकि फिक्स-प्रतिक्रिया-हल-बंद को उस मामले से बचना चाहिए

यह मानता है कि उठाए गए सभी कीड़े एक ही समय में तय किए जाएंगे। एक परिदृश्य की कल्पना करें जहां एक टिकट दो मुद्दों के साथ उत्पाद के खिलाफ उठाया जाता है:

  1. फ़ार्म रीसेट बटन वास्तव में फ़ॉर्म को सबमिट करता है, मूल्यों को साफ़ करने के बजाय
  2. बटन पर फ़ॉन्ट-आकार 110% है जब यह 115% होना चाहिए।

एक परीक्षक के लिए दोनों सही हैं, क्योंकि वे कार्यान्वयन के साथ दोनों दोष हैं। लेकिन मान लें कि उत्पाद का मालिक यह तय करता है कि पहला उपमा रिलीज करने के लिए अवरोधक है (यानी उत्पाद को लाइव होने से पहले इसे ठीक करना होगा), लेकिन दूसरा कार्य एक मामूली समस्या है (यानी यह v1 में तय किया जा सकता है)। 1 रिलीज)।

उस स्थिति में, हमारे पास # 2 को खुद के टिकट में विभाजित करने के लिए (या इसके बारे में भूल जाने का जोखिम) के अलावा कोई विकल्प नहीं है। यदि हम ऐसा कर सकते हैं, तो इसका मतलब है कि वे एक-दूसरे से स्वतंत्र रूप से कार्यान्वित, परीक्षण और तैनात किए जा सकते हैं, जिस स्थिति में यह शुरू से ही व्यक्तिगत मुद्दों को समझने में मदद करता है।


2
और उन दो मुद्दों को बहुत अच्छी तरह से दो अलग-अलग इंजीनियरों द्वारा तय किए जाने की आवश्यकता हो सकती है - इस उदाहरण में, एक जो HTML फॉर्म लॉजिक को हैंडल करता है और एक जो सीएसएस स्टाइलशीट को संभालता है। यदि दो बग हैं, तो प्रत्येक इंजीनियर को उनके हिस्से को सौंपा जाता है, लेकिन कई बग ट्रैकिंग सिस्टम एक बग को दो अलग-अलग लोगों को सौंपने का काम नहीं कर सकते हैं।
अलंक जूल

6

स्कोप:

यह उत्तर (और प्रश्न) केवल कोड दोषों की ट्रैकिंग पर लागू होता है, जहां स्रोत कोड विनिर्देश या प्रोग्रामर के इरादों के अनुसार प्रदर्शन नहीं करता है।

इसके विपरीत, जीयूआई दोष टिकटों में कई विशिष्टताओं को शामिल करना आम है, क्योंकि प्रत्येक जीयूआई टिकट प्रभावी रूप से एक "नया स्वरूप" (डिजाइन दोष), एक "संशोधित विनिर्देश" या एक "सुविधा अनुरोध" (लापता कार्यक्षमता) है।


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

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

कोड दोष ट्रैकिंग प्रणाली का उद्देश्य है:

  • स्वतंत्र रूप से प्रजनन योग्य दोषों के स्वतंत्र और अस्पष्ट ट्रैकिंग को सक्षम करने के लिए , और
  • प्रत्येक दोष के मूल कारण के लिए सबसे अच्छा सन्निकटन (एक-से-एक पत्राचार) प्रदान करना।

ऐसा करते समय, यह निम्नलिखित वांछनीय गुणों को अधिकतम करना चाहिए:

  • समय के साथ दोषों की संख्या बढ़ने पर कुशलता से पैमाने।
  • मूविंग-टारगेट सिंड्रोम को रोकें।

डिस्क्लेमर: यह रीफ़्रेज़ मेरे व्यक्तिगत अनुभव से है। प्रमाणन परीक्षा के उद्देश्य के लिए यह अपर्याप्त या गलत हो सकता है।


स्वतंत्र और अस्पष्ट ट्रैकिंग का मतलब है कि:

  1. प्रत्येक वैध दोष अस्पष्टता के बिना या तो हल किया जा सकता है या हल नहीं किया जा सकता है।

    • कारण 1: प्रबंधन को सरल बनाना,
      • उदाहरण: यह मीट्रिक के रूप में "अनसुलझे टिकटों की संख्या" के उपयोग को सक्षम करता है।
    • कारण 2: कार्रवाई योग्य आइटम में अनुवाद करना
      • उदाहरण: यदि इसका समाधान नहीं किया गया है, तो जिम्मेदारी निर्धारित प्रोग्रामर पर है। यदि इसे हल किया जाता है, लेकिन बंद नहीं किया जाता है, तो जिम्मेदारी असाइन किए गए परीक्षक (सत्यापनकर्ता) पर निहित है।
    • परिणाम: इस पद्धति में, आंशिक रूप से हल किया गया दोष कई आश्रित दोषों में टूटने के योग्य है।
  2. स्वतंत्र रूप से प्रजनन योग्य दोषों को स्वतंत्र रूप से ट्रैक किया जाना चाहिए।

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

4

सिस्टम का उपयोग करते हुए किसी और के दृष्टिकोण से इसे देखें, कुछ महीने बाद दिखा। वे कार्यक्रम में एक बग पाते हैं। वे Google के चारों ओर देखते हैं कि एक समर्थन टिकट है जो उनकी समस्या से मेल खाता है। और हे, यह बंद है! बहुत बढ़िया! यह नवीनतम संस्करण में तय किया गया है! तो, वे अद्यतन ... और बग अभी भी वहाँ है? इन बेवकूफ डेवलपर्स के साथ क्या गलत है?!?

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

प्रत्येक बग को अपना टिकट देना बेहतर है, और यदि आपके पास कई बग हैं जो संबंधित हैं, लेकिन स्पष्ट रूप से अलग हैं, तो अधिकांश बग ट्रैकिंग सिस्टम में एक सुविधा है जो आपको एक बग को दूसरे से लिंक करने की सुविधा देती है। (और यदि नहीं, तो आप इसे रिपोर्ट में डाल सकते हैं। "बग # 12345 भी देखें।"


धन्यवाद, क्या आप Bतब चुनेंगे?
आइरिस

@Ofiris: हाँ, मैं करूँगा।
मेसन व्हीलर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.