आपकी बग प्रबंधन प्रक्रिया क्या है?

Question

एक बग की जीवन चक्र/प्रक्रिया क्या है? आम तौर पर बोलते हुए, क्या कोई सुझाव है, सुझाव प्रक्रिया के अनुसार कि बग फिक्सिंग हालांकि जाना चाहिए?

Answer 1

मानक Find-> Fix-> टेस्ट रिलीज चक्र से परे कुछ बातें:

• एक बग कई कार्य करना चाहिए था, तो यह फिक्सिंग के लिए एक व्यक्ति को सौंपा जा सकता है, और किसी अन्य व्यक्ति के लिए एक व्यक्ति को सौंपा जा रहा है, इसकी जांच।

• आपकी बग ट्रैक सिस्टम को जो भी बदला गया था, उसके इतिहास को ट्रैक करना होगा।

• ट्रैक रखें कि किस संस्करण में एक बग मिला था, इसमें तय किया गया था, और फिर जारी किया गया था। वे सभी अलग-अलग और महत्वपूर्ण मूल्य हैं।

• किसी समस्या को बढ़ाने के लिए किसी समस्या को बदलने की क्षमता है।

• किसी व्यवसाय विश्लेषक को प्रश्नों को प्रस्तुत करने के लिए "प्रश्न" या "उत्तर के लिए प्रतीक्षा" की स्थिति है, अनिवार्य रूप से बग पर प्रगति को अवरुद्ध कर रहा है।

• एक बग को एक ही मुद्दे तक सीमित रखें, ताकि आप यह सत्यापित कर सकें कि वह समस्या ठीक से तय की गई है या नहीं। तो यदि स्क्रीन के साथ 3 चीजें गलत हैं, तो 3 बग लॉग करें, इसके बजाय "जो भी स्क्रीन पर समस्याएं"; इन बग को अलग-अलग तय किया जा सकता है और व्यक्तिगत रूप से जारी किया जा सकता है, और आपको इसे ट्रैक करने में सक्षम होना चाहिए।

Answer 2

टेस्ट (सॉफ्टवेयर) -> प्रवेश करें (बग) -> फिक्स -> सत्यापित करें -> बंद

Answer 3

1. उपयोगकर्ता रिपोर्ट बग
2. क्यूए reproduces बग
3. एक देव सत्यापित करने के लिए बग triages क्या यह एक बग या एक नई सुविधा अनुरोध
4. यदि यह एक बग है, यह एक देव
5. क्यूए के लिए निर्दिष्ट की परीक्षण अगली फिल्म में बग फ़िक्स
6. रिलीज
01 है

Answer 4

1. बग पर ध्यान दें।
2. बग खोजें, इसे पुन: उत्पन्न करने में सक्षम हो।
3. कोड समाधान, बग को ठीक करें।
4. परीक्षण - साबित करें कि आपने बग को ठीक किया है और नई बग (कार्यक्षमता और इकाई परीक्षण) पेश नहीं किया है।
5. पुनर्वितरण या पैच।

सरल प्रश्न, सरल उत्तर। उम्मीद है की यह मदद करेगा।

Answer 5

विषय पर एक अच्छी किताब है:

Debugging डेविड J अगन्स द्वारा जिनमें से

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

कई बार ऐसा हुआ है जब मैंने फिक्स (रखरखाव कोड में) केवल यह पता लगाने के लिए किया कि फिक्स अन्य चीजों को तोड़ दिया है। निश्चित रूप से बग को चिह्नित करने से पहले यह सुनिश्चित करें कि फिक्स कुछ और नहीं तोड़ता है।

जो एक बग का असली मुद्दा लाता है: कोड को क्या कर रहा है पूरी तरह से समझने में विफलता।

Answer 6

जब मुझे कोई बग मिलती है, तो सबसे पहले मैं इसे बग सिस्टम में लॉग करता हूं। फिर मैं बग को चित्रित करने के लिए परीक्षण लिखता हूं, फिर यह सुनिश्चित करने के लिए कोड को ठीक करता हूं कि परीक्षण पास हो जाता है। यह सुनिश्चित करता है कि आप ए) बग को पुन: उत्पन्न कर सकते हैं और बी) बग को ठीक करें।

समय-समय पर, यह बग डेटाबेस पर कुछ विश्लेषण करेगा कि यह पता लगाने के लिए कि बग क्यों हो रहे हैं। क्या स्पेस में त्रुटियां हैं, कोड में तर्क त्रुटियां इत्यादि हैं? और बग गणना को कम करने के लिए उचित उपाय करें।

मैंने इसे अपने ब्लॉग http://jeffastorey.blogspot.com/2010/02/what-to-do-when-you-find-bug.html में विस्तृत किया है।

Answer 7

मेरे संगठनों इस पैटर्न का पालन किया है:

1. सिस्टम इंजीनियर या गुणवत्ता आश्वासन बग देखती है और बग ट्रैकिंग उपकरण में यह प्रवेश करती है।

2. पीएम या देव लीड गंभीरता, संभावित कामकाज और इसे ठीक करने के लिए आवश्यक प्रयास के अनुसार बग को प्राथमिकता देते हैं।

3. पीएम या देव लीड एक डेवलपर को बग असाइन करता है।

4. डेवलपर 1.

5. डेवलपर कोड एक समाधान चरण में व्यक्ति से ऐसा कोई आवश्यक मदद से बग reproduces, और एक का निर्माण करता है (या बनाया निर्माण होता है)।

6. चरण 1 से परीक्षक बग को प्रतिस्थापित करता है।

7. यदि बग ठीक है, पुन: नियोजित या पैच। अन्यथा, जब तक यह तय नहीं हो जाता है तब तक चरण 5 और 6 दोहराएं या अधिक दबाव वाली समस्या प्राथमिकता लेती है।

8. यदि ग्राहक द्वारा बग पाया गया था, तो उनके साथ सत्यापित करें कि यह तय है।

आम तौर पर, कीड़े इस असाइनमेंट चक्र के माध्यम से जाना: परीक्षक -> (प्रधानमंत्री/लीड, तो डेवलपर, या डेवलपर) -> परीक्षक -> PM/लीड -> बंद रहता है।

Answer 8

मैं यहां snarky पाने में मदद नहीं कर सकता। मैंने कोशिश की लेकिन आखिरकार टूट गया। वास्तविक बग प्रक्रिया:

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

शाखा 1 देव स्क्रीन शॉट प्रदान की को देखता है और देखती है कि उपयोगकर्ता 2009 रिपोर्टिंग पृष्ठ पर 2010 के आंकड़े की तलाश में है:

यहां से तीन शाखाएं हैं। उपयोगकर्ता त्रुटि और बग बंद की सूचना दी।

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

ओह, वास्तव में एक वास्तविक बग है, देव फिक्स और चालें प्रोड को ठीक करने और बग को बंद करने के लिए ठीक करती हैं।

Answer 9

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

विचारणीय बातें:

• त्रुटि आवृत्ति
• उन पर असर पड़ा अपने कोड की
• क्षेत्र
• वीआईपी ग्राहकों

चीजें मदद कर सकते हैं को प्राथमिकता कीड़े को आसान बनाने:

• बुद्धिमान चेतावनी
• मौन या त्रुटियों
• याद दिला सकते हैं त्रुटियों की तरह उपयोगकर्ताओं के लिए एक साथ
• मानचित्रण त्रुटियों समूहीकरण
• एक ही स्थान पर अपने सिस्टम के पार से त्रुटियों को मजबूत करने की क्षमता।

आप और अधिक उपयोगी सुझाव यहाँ पा सकते हैं: https://blog.bugsnag.com/bug-prioritization/