बग रिपोर्ट संकलित करते समय सामान्य गलतियाँ

Habré पर एक अच्छी प्रोग्रामिंग शैली, नामकरण सम्मेलन के बारे में बहुत कुछ लिखा गया है। और बग रिपोर्ट के लिए एक अच्छी लेखन शैली के बारे में क्या?

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

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

1. एक बहुत ही सामान्य हेडर बग

इस तरह के कीड़े का एक उदाहरण : मैं एक खाता नहीं बना सकता।
सिस्टम पूरी तरह से निष्क्रिय हो रहा है। समस्या के अधिक विस्तृत अध्ययन के साथ क्या हो सकता है:

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

वैसे, प्लेबैक चरणों में इन सभी विवरणों (ब्राउज़र संस्करण, स्थानीयकरण) को इंगित नहीं किया जा सकता है।

2. बहुत विस्तृत पूर्व-चरण, बहुत छोटा विवरण।

उदाहरण : मैंने एक दीवार में कील ठोक दी। फिर उन्होंने बोल्ट, नट और शीट मेटल के साथ काम किया। समस्या: अंतरिक्ष यान नहीं उड़ता है।

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

3. त्रुटि की प्रत्येक अभिव्यक्ति के लिए, एक अलग बग रिपोर्ट बनाएं

हां, कभी-कभी यह स्पष्ट नहीं होता है कि यह वास्तव में एक ही समस्या है। लेकिन कभी-कभी एक ही दोष की विभिन्न अभिव्यक्तियां अलग-अलग डेवलपर्स पर पड़ती हैं और फिर भ्रम शुरू होता है।

4. बड़ी संख्या में अटैचमेंट और लिंक

ऐसे बग में आमतौर पर केवल हेडर होता है। प्लेबैक चरण परीक्षण-मामले की एक कड़ी है (वैसे, शायद प्रोग्रामर के पास ऐसे संसाधन तक पहुंच अधिकार नहीं है), अपेक्षित परिणाम 50-पृष्ठ के दस्तावेज़ का लिंक (या अनुलग्नक) है। कमेंट्री में एक नोट हो सकता है कि प्लेबैक चरणों को विस्तार से वर्णित किया गया है, नं। एनएनएन। पूरक के रूप में - एक लॉग। पूरे। परीक्षण के सभी 2 सप्ताह के लिए। सभी 50 मेगाबाइट। खैर, प्रत्येक चरण के स्क्रीनशॉट एक बोनस हैं।

5. यह इंगित नहीं किया जाता है कि वास्तव में त्रुटि क्या है।

हां, ऐसा होता है। शायद ही कभी (यह सूची में पहला नहीं है), लेकिन ऐसा होता है

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

6. विशिष्ट संक्षिप्तीकरण और संक्षिप्तीकरण का उपयोग

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

7. सब कुछ के बारे में और कुछ नहीं के बारे में

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

यह मुझे लगता है कि ये सिफारिशें बगों के विवरण की गुणवत्ता में सुधार कर सकती हैं:

1 बग ट्रैकिंग सिस्टम में आवश्यक फ़ील्ड को सही ढंग से कॉन्फ़िगर करें, बड़ी फ़ाइलों को संलग्न करने पर रोक (यदि यह एक त्रुटि वीडियो प्लेबैक नहीं है)
2. कोड-समीक्षा के साथ सादृश्य द्वारा: कभी-कभी सहकर्मियों को नए सिरे से उत्पन्न त्रुटि रिपोर्ट को देखने के लिए कहें। शायद वे आपको बताएंगे कि बग के विवरण से क्या जोड़ना है और / या बाहर करना है।
3. नई रिपोर्ट बनाने से पहले बगबेस की जाँच करें - शायद ऐसा "जानवर" पहले से ही रिकॉर्ड किया गया है।
4. हर जगह एक मध्य मैदान की जरूरत होती है। महत्वपूर्ण चरणों को याद किए बिना लिखने की कोशिश करें, लेकिन स्पष्ट चीजों को चबाने के बिना
5. और सुनहरे नियम के बारे में मत भूलना - त्रुटि रिपोर्ट लिखें ताकि आपको उन्हें पढ़ने में आनंद आए