बग के साथ कैसे निपटा जाए जो लगता है कि खुद तय हो गया है? [बन्द है]

Question

मैं एक आंतरिक प्रणाली के लिए एक वेब एप्लिकेशन डेवलपर हूं। एक उपयोगकर्ता रिपोर्ट करता है कि बग है।

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

मुझे ग्राहक और उपयोगकर्ता को कैसे जवाब देना चाहिए?

Comments

प्रोग्रामर पर हमारे यहां कई संबंधित प्रश्न हैं: यदि कोई प्रजनन योग्य परीक्षण मामला मौजूद नहीं है, तो बग को दूर करें? मैं बग को पुन: उत्पन्न करने के लिए मुश्किल कैसे अलग करूं? सबसे प्रभावी रूप से डिबग कोड कैसे करें? अन-समझदार कीड़े? उन बगों के साथ क्या करना है जो फिर से नहीं करते हैं?

— थॉमस ओवेन्स

यह दोहराने योग्य बनाने के लिए कैसे पता लगाएं।

— व्याट बार्नेट

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

— न्यूटोपियन

यह सिर्फ एक सुंदर मानक बॉयलरप्लेट प्रतिक्रिया के लिए कहता है: " प्रिय [उपयोगकर्ता], एक्स के साथ समस्या जिसे आपने यूथ पर रिपोर्ट किया है, को जेड की नवीनतम रिलीज के साथ हल किया गया है। कृपया समस्या के रूप में हल किए गए मुद्दे को चिह्नित करें यदि वास्तव में ऐसा है। । अगर आपने इसका सामना किया, तो विवरण के साथ कृपया मुझे वापस न भेजें। "

— लिलिएनथल

@ लिलिंथल सिर्फ इसलिए कि बग को पुन: पेश नहीं किया जा सकता इसका मतलब यह नहीं है कि इसे हल कर दिया गया है। आपको यह भी पता नहीं है कि पिछले महीने में कोई नई रिलीज़ भी हुई है।

— पपराज़ो

Answer 1

बग पर देखे गए संस्करण के लिए अपने देव परिवेश को वापस लाएं और सत्यापित करें कि बग वहां मौजूद है।

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

यदि आप उस संस्करण में बग को पुन: उत्पन्न नहीं कर सकते हैं, तो यहां कई अन्य प्रश्नों में निर्धारित रणनीतियों का उपयोग किया जाएगा (प्रारंभिक सूची के लिए धन्यवाद थॉमस):

• अगर कोई प्रतिलिपि प्रस्तुत करने योग्य परीक्षण मामला मौजूद है, तो एक बग को दूर करें?
• मैं बग को पुन: उत्पन्न करने के लिए मुश्किल कैसे अलग करूं?
• सबसे प्रभावी रूप से डिबग कोड कैसे करें?
• अन-समझदार कीड़े?
• उन बगों के साथ क्या करना है जो फिर से नहीं करते हैं?

Comments

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

— पॉल जे एबरनेथी

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

— शाफ़्ट सन 19

@ratchetfreak वैकल्पिक रूप से, यह इस बात पर निर्भर करता है कि यह विशेष ग्राहक कितना गंभीर है। अगर वे आपकी तनख्वाह के लिए धनराशि दे रहे हैं, तो शायद उनके लिए यह उचित है ;-)

— Cort Ammon - Monica

समस्याएं जो खुद से दूर हो जाती हैं वे खुद से वापस आती हैं।

— पीट बेकर

यह सब काम के बोझ की बात है। यदि आपके पास एक बग है जो एक महीने पहले प्रतिलिपि प्रस्तुत करने योग्य था और अब नहीं है, और दूसरा बग जो अब प्रतिलिपि प्रस्तुत करने योग्य है , तो आप उस प्रतिलिपि को ठीक करते हैं जो अब पहले प्रतिलिपि प्रस्तुत करने योग्य है। यदि आप कभी ऐसी अवस्था में पहुँचते हैं जहाँ आप पूरी तरह से ऊब चुके हैं, तो आप जांच कर सकते हैं। और जब समस्या अपने आप वापस आती है, तो निश्चित रूप से यह एक प्रतिलिपि प्रस्तुत करने योग्य बग है और आप इसे ठीक करना शुरू करते हैं :-)

— gnasher729

Answer 2

मुझे लगता है कि आप वास्तव में बग को पुन: पेश करने के लिए सब कुछ कर सकते हैं, लेकिन ऐसा नहीं कर सकते हैं।

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

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

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

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

Answer 3

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

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

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

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