एक अच्छा बग डेटाबेस बनाए रखने के लिए कदम

9

बग डेटाबेस को बनाए रखना हर परियोजना के लिए एक महत्वपूर्ण है। मैं बग डेटाबेस पर फ़ॉलोइंग को संग्रहीत करने के लिए उपयोग किया जाता हूं

जारी करने का समय
किसे सौंपा गया है
इसे हल किया गया है या नहीं
यदि तब हल किया गया, तो दिनांक समय हल किया गया

क्या वे एक अच्छे बग डेटाबेस को बनाए रखने के लिए पर्याप्त हैं?

bug bug-report

— CoolProgrammer
स्रोत

क्या यह एक बग ट्रैकिंग डेटाबेस है?

— यूसुबोव

1

जिज्ञासा से बाहर, क्या आप अपनी परियोजनाओं पर बग को ट्रैक करने के लिए अपना बग ट्रैकिंग डेटाबेस लिखने की योजना बना रहे हैं? यदि हाँ, तो क्या आपने स्वतंत्र रूप से उपलब्ध उत्पादों के एक टन को देखा है जो पहले से ही ऐसा करते हैं?

— DXM

12

एक अच्छे बग डेटाबेस का अनुसरण हो सकता है

// तिथि समय संबंधित

बग की तारीख जारी करें
अपेक्षित समय / समाधान दिनांक की समय-सीमा
यदि तब हल किया गया, तो दिनांक समय हल किया गया

// असाइन किया गया + से

द्वारा निर्दिष्ट (द्वारा पता लगाया गया)
को सौंपना

// बग व्यवहार

अवलोकित (छोटी गाड़ी) व्यवहार
स्क्रीन शॉट (संभव है)
बग को पुन: पेश करने के लिए पूर्ण चरण
अपेक्षित् व्यवहार

// प्राथमिकता

बग की प्राथमिकता

// लिंक, स्थिति और अन्य

संबंधित कीड़े का लिंक
बग की स्थिति
इसे हल किया गया है या नहीं
यदि हल किया गया है, तो स्पष्टीकरण के साथ कैसे हल किया गया है

संपादित करें: मैं भी सिफारिश करना चाहता हूं

बग की खोज किस संशोधन / शाखा में की गई थी
किस संशोधन / शाखा में बग को ठीक किया गया है

संपादित करें: मुझे @ jgauffin की टिप्पणी पसंद है

न ठीक, न बग, न डुप्लीकेट, हल

EDIT: एक अच्छा बग डेटाबेस सिस्टम भी बनाए रखता है

जिम्मेदारी असाइनमेंट मैट्रिक्स

— एमडी महबूबुर्रहमान
स्रोत

आप इस तरह का समाधान भूल गए: न ठीक, न बग, न डुप्लीकेट, हल

— jgauffin

@jgauffin, अच्छी टिप्पणी। मैंने आपकी टिप्पणी के संबंध में अपना उत्तर संपादित कर दिया है।

— एमडी महबूबुर रहमान

3

कई कस्टम फ़ील्ड हो सकते हैं जिन्हें आपको प्रोजेक्ट की ज़रूरतों के आधार पर लॉग इन करने की आवश्यकता हो सकती है। मैं निम्नलिखित सूची के साथ आया था जिस पर आपको विचार करने की आवश्यकता हो सकती है:

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

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

— Yusubov
स्रोत

2

लगता है कि अधिकांश उपयोगी क्षेत्र पहले से ही अन्य उत्तरों से आच्छादित हैं, लेकिन कुछ ऐसे हैं जो मुझे उपयोगी लगते हैं:

बग की खोज किस संशोधन / शाखा में की गई थी।
किस संशोधन / शाखा में यह तय किया गया है।

यह किस दिनांक / समय पर बग की खोज / नियत की तुलना में थोड़ा अधिक विशिष्ट है।

यदि आपका सॉफ़्टवेयर कई प्लेटफ़ॉर्म (OS या हार्डवेयर) पर चलता है, तो आप एक फ़ील्ड भी चाहते हैं जो उन प्लेटफार्मों को सूचीबद्ध करता है जहां बग होता है।

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

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

— हेराल्ड
स्रोत

2

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

खोला गया दिनांक
द्वारा खोला गया
हल की गई तारीख
द्वारा हल किया गया
समय बिताया
कैसे हल किया गया
आदि।

आपको ट्रैक करने के लिए भी एक समान तालिका की आवश्यकता हो सकती है कि किसको और कब बग को सौंपा गया था (खासकर) यदि आप एक बड़ी टीम में काम करते हैं।

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

— Superm
स्रोत

2

बग ट्रैकिंग की प्रक्रिया डेटा की तरह ही महत्वपूर्ण है। निम्नलिखित के बारे में भी सोचने की कोशिश करें:

उपयोगकर्ता बग की रिपोर्ट कैसे करते हैं?
बग का भंडार में कौन प्रवेश करता है?
बग की पुष्टि कौन कर सकता है?
बग की पुष्टि कौन कर सकता है?
अंत उपयोगकर्ता को कौन सूचित करता है कि बग हल हो गया है?

अपनी टीम में सभी के लिए एक RACI चार्ट बनाएँ (अंतिम उपयोगकर्ताओं सहित उनकी ज़िम्मेदारियों को जानता है। उचित डेटा प्रविष्टि तकनीकों के साथ इसे मिलाएं और आपको थोड़े अतिरिक्त प्रयास के साथ बहुत अधिक मूल्य दिखाई देगा।

— चाड कपैच
स्रोत