मेन्यू

यह परिदृश्य स्पष्ट करता है कि अक्सर एनकाउंटर किए गए त्रुटियों का दस्तावेज़ीकरण करना कितना महत्वपूर्ण है

  • मुख्य
  • बग दोष ट्रैकिंग
  • यह परिदृश्य स्पष्ट करता है कि अक्सर एनकाउंटर किए गए त्रुटियों का दस्तावेज़ीकरण करना कितना महत्वपूर्ण है

this scenario explains how important it is document frequently encountered errors

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

क्या आप मानते हैं कि सॉफ़्टवेयर त्रुटियां केवल एक बार होती हैं और यह तय होने पर कि वे कभी पुनर्जीवित नहीं होती हैं? मुझे लगता है कि त्रुटियों के बारे में 30% reoccur।

इस लेख में, मैं यह कवर करना चाहता हूं कि अक्सर सामना की जाने वाली त्रुटियों में से कुछ को दस्तावेज करना कितना महत्वपूर्ण है।

नीचे, आपको कुछ मिलेंगे सामान्य क्षेत्र जहाँ मुद्दे देखे जाते हैं और उन्हें प्रलेखित करने के लिए एक खाका।

आशा है कि आप इसे उपयोगी पाएंगे!

बार-बार एनकाउंटर किए गए त्रुटियों का दस्तावेजीकरण

छवि स्रोत

परिद्रश्य 1

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

दस्तावेज संबंधी त्रुटियाँ १

दस्तावेज संबंधी त्रुटियाँ २

जॉन और शेरिल दोनों स्मिथ की तलाश में गए, जिन्होंने पहले भी वही त्रुटि देखी थी और इसे पहले हल किया था। दुर्भाग्य से, स्मिथ उस दिन छुट्टी पर थे।

अब जॉन को क्या करना चाहिए? क्या जॉन स्मिथ के अनुपलब्ध होने पर भी कोई संकल्प खोजने के लिए स्मिथ तक पहुँचने का प्रयास करना चाहिए?

इसलिए, यदि कोई पर्यावरण समस्या कई रिलीज़ पर बार-बार देखी जाती है, विवरणों को दस्तावेजित करना एक अच्छा विचार है और इसे साझा स्थान पर रखें। यह किसी एक व्यक्ति पर निर्भरता को समाप्त कर देगा और ऐसा होने पर सभी टीम के सदस्यों को स्वयं एक संकल्प खोजने में मदद करता है।

परिदृश्य # 2

जॉन एक नई रिलीज का परीक्षण कर रहा है और फिर से एक ज्ञात त्रुटि पर आता है। इस बार, वह जानता है कि पिछले रिलीज में से एक में इसके लिए एक दोष बनाया गया था। लेकिन सवाल यह है: 'मैं दोष संख्या और अन्य संबंधित विवरणों को कैसे खोजूं?'

इस मामले में भी, आपको क्या लगता है कि जॉन मदद करेगा?

ये संभावनाएं हैं।

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

आप क्या सीखेंगे:

लगातार त्रुटियों वाले कुछ क्षेत्र:

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

2) URL गलत DB की ओर इशारा करता है

3) प्रवेश मुद्दे - जब उपयोगकर्ता डीबी या इस मामले में अपर्याप्त या गलत पहुंच की अनुमति देते हैं, तो उपयोगकर्ता समस्याओं में भाग लेते हैं और इस मामले में किसी व्यक्ति या व्यक्ति से संपर्क किए जाने वाले कदमों की रूपरेखा तैयार करने वाला एक दस्तावेज सुपर सहायक होगा।

4) टेस्ट डाटा इश्यू - गलत प्रारूप या डेटा के मूल्यों का उपयोग करना मुद्दों में परिणाम नहीं होने की तुलना में अधिक बार होगा।

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

ज्यादातर बार-बार होने वाली त्रुटियां हैं पर्यावरण के मुद्दें ।

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

मुफ्त यूट्यूब एमपी 3 कनवर्टर प्रीमियम के लिए

दोषों का एक छोटा क्षेत्र भी हो सकता है डेटा प्रविष्टि या मानव उपयोग गलती रों ।

डाउनलोडअक्सर त्रुटियों का सामना करने के लिए टेम्पलेट

शब्द प्रारूप

=> डाउनलोड त्रुटि ट्रैकिंग टेम्पलेट (विश्व)

एक्सेल प्रारूप

=> त्रुटि ट्रैकिंग टेम्प्लेट (एक्सेल) डाउनलोड करें

दस्तावेज़ीकरण के लाभ अक्सर त्रुटियों का सामना करना पड़ा

1) निर्भरता को खत्म करता है - परिदृश्य 1 में, जॉन संकल्प के लिए स्मिथ पर निर्भर थे। जॉन के संदर्भ के लिए एक दस्तावेज था जो मामला नहीं होगा।

2) तेजी से बदलाव - परिदृश्य लें 2. एक परीक्षक को पहले से ही लॉग किए गए दोषों की पूरी सूची से नहीं गुजरना होगा यदि उच्च आवृत्ति समस्याओं के लिए एक समर्पित दस्तावेज़ था।

3) टीम के नए सदस्यों को आत्मनिर्भर होने में मदद करता है

4) मानवीय त्रुटियों को हल करने में सहायता करता है

निष्कर्ष

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

परीक्षण निष्पादन जारी होने के दौरान यह दस्तावेज़ के लिए थकाऊ हो सकता है, लेकिन एक सर्वोत्तम अभ्यास के रूप में, निष्पादन के दौरान मोटे नोट लिए जा सकते हैं, जिन्हें बाद में संक्षेप में और साझा दस्तावेजों में अपडेट किया जा सकता है।

अनुशंसित पाठ

^