3 सबसे खराब दोष रिपोर्टिंग की आदतें और उन्हें कैसे तोड़ना है

3 worst defect reporting habits

दोष गंभीर व्यवसाय हैं और छोटी गलतियां महंगी हो सकती हैं।

आप जानते हैं कि जब आप एक दोष पाते हैं तो क्या करें। आप इसकी रिपोर्ट करते हैं; या तो में दोष ट्रैकर / दोष प्रबंधन उपकरण या एक एक्सेल शीट में। अंतर्निहित सिद्धांत दोनों विधियों के लिए समान हैं।

दोष प्रबंधन उपकरण बेहतर रिपोर्टिंग की गारंटी नहीं देते हैं। यह अच्छी प्रथा है जो दिन को बचाती है।

अच्छे की सराहना करने के लिए, हमें यह पहचानना चाहिए कि क्या नहीं है।

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

• 3 सबसे खराब दोष रिपोर्टिंग की आदतें और उन्हें कैसे तोड़ना है
• (१) आलस्य
• # 2) दौड़ना
• # 3) रचनात्मकता का अभाव
• अनुशंसित पाठ

3 सबसे खराब दोष रिपोर्टिंग की आदतें और उन्हें कैसे तोड़ना है

यहाँ जाता है:

(१) आलस्य

सबसे अच्छा करने के लिए समय नहीं ले रहा है कि आप कर सकते हैं।

यह है दोष ट्रैकिंग प्रक्रिया अधिकांश टीमों में पीछा किया:

()ध्यान दें- बढ़े हुए दृश्य के लिए किसी भी छवि पर क्लिक करें)

जैसा कि आप देख सकते हैं, टेस्ट लीड ने क्यूए टीमों से बाहर भेजने से पहले दोषों की समीक्षा की।

इस समीक्षा में पुष्टि करना शामिल है:

• वैधता- क्या यह एक बग है?
• पूर्णता- शीर्षक, चरण, डेटा, स्क्रीनशॉट आदि।
• डुप्लिकेट
• प्रतिशोधी या नहीं… आदि।

मैं पहले से जानता हूं कि क्यूए लीड के लिए 100% पूरी तरह से असंभव है।

इसलिए, रवैया, 'मैं समस्या को रिपोर्ट करूँगा जिस तरह से मैं चाहता हूँ। क्यूए लीड पुनरावृत्ति कर सकता है। वह यह तय कर सकता है कि क्या दोष वैध / पूर्ण है या नहीं ”आपकी QA टीम और आपकी विश्वसनीयता का अंत है।

क्या आप जानते हैं कि कुछ ग्राहकों के पास स्वीकार्य अमान्य दोषों की संख्या के लिए एक SLA है? एक बार संख्या से अधिक हो जाने पर, वे रिपोर्ट किए गए प्रत्येक अमान्य दोष के लिए ठेकेदारों को दंडित करना शुरू करते हैं?

निदान: अपना उचित परिश्रम करो और अपने उद्धार के लिए जिम्मेदार बनो। एक दोष पर्याप्त जानकारी के लिए वापस आया या यह बग नहीं है? यह हमेशा विकास टीम की गलती नहीं हो सकती है। ऐसा नहीं है कि वे आवेदन में आने वाली समस्याओं के स्वामी नहीं हैं। यह एक वास्तविक क्यूए टीम गड़बड़ हो सकती है। ऐसा न होने दें

# 2) दौड़ना

चलो यह एक के साथ हैउदाहरण।

नीचे एक स्क्रीन शॉट है OpenEMR का रोगी स्क्रीन बनाएँ। यह एक ओपन सोर्स हॉस्पिटल मैनेजमेंट सिस्टम है।

यह स्क्रीन उपयोगकर्ता को कैलेंडर सुविधा के माध्यम से रोगी की जन्म तिथि दर्ज करने देती है। यह जो नहीं करता है वह कैलेंडर से चुनने के लिए प्रवेश को प्रतिबंधित करता है। मेरा मतलब है, आप कैलेंडर से '31-मार्च-1983' के रूप में DOB चुन सकते हैं। बाद में इसे '31-फरवरी-1983' में बदल दें।

31 फरवरी ही क्यों? लागू करने के लिए अनुमान लगाने में त्रुटि और क्षेत्र में एक नकारात्मक डेटा का प्रयास करें; जो परीक्षण के पूरे बिंदु है, क्या यह नहीं है?

एक बार करने के बाद, मैं 'रोगी बनाएँ' पर क्लिक करता हूं। चूंकि तारीख अमान्य है, इसलिए मुझे उम्मीद है कि सिस्टम एक त्रुटि प्रदर्शित करेगा और रोगी नहीं बनाएगा। लेकिन ऐसा नहीं होता है। यह रोगी को नीचे के रूप में बनाता है।

नीचे दिए गए स्क्रीन में जन्म क्षेत्रों की आयु और तारीख नोट करें:

परीक्षण करते समय, आप इसे कुछ बार आज़मा सकते हैं और यह तय कर सकते हैं:

• यह एक बग है।
• यह प्रजनन योग्य है।
• यह डुप्लिकेट नहीं है (पुष्टि करने के लिए अपनी टीम के साथ जांचें)
• आप समस्या का सटीक विवरण जानते हैं
• इसके अलावा, आप सटीक चरणों को जानते हैं जो इसे पूरा करते हैं।

अब जब आपके पास कच्चा माल है, तो आप जाने के लिए अच्छे हैं।

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

चूंकि यह दोष सिस्टम को क्रैश नहीं कर रहा है या एक महत्वपूर्ण कार्यक्षमता को अवरुद्ध कर रहा है या एप्लिकेशन के अन्य क्षेत्रों को परीक्षण करने से रोक रहा है, इसलिए हम 'कम' के साथ जा सकते हैं।

सही लगता है?

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

यह दवाओं और कई अन्य उपचार क्षेत्रों की खुराक को प्रभावित करता है, जिनके बारे में हम जानते भी नहीं हैं।

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

एक परीक्षक के रूप में मेरा काम यह सुनिश्चित करना है कि मैं समस्या की गंभीरता को यथासंभव सर्वोत्तम तरीके से संप्रेषित कर सकूं।

निदान: रिपोर्ट करने की जल्दी में नहीं हैं। 100% सुनिश्चित रहें कि आप कई कोणों से समस्याओं के प्रभाव को समझते हैं। यह सबसे अच्छा मूल्य-वर्धक है जिसे हम परीक्षक प्रदान कर सकते हैं। हम सिर्फ यह नहीं कह रहे हैं, 'कुछ काम नहीं कर रहा है'। हम यह भी कह रहे हैं, 'अगर यह काम नहीं करता है तो क्या होगा।' टोंस ऑफ़ डिफरेंस, क्या यह नहीं है?

# 3) रचनात्मकता का अभाव

परीक्षकों के पास सॉफ्टवेयर को बेहतर बनाने के लिए सुझाव देने का एक शानदार अवसर है।

अपने में दोष प्रबंधन उपकरण भी, आप 'सुधार सुझाव' का एक प्रकार प्रस्तुत कर सकते हैं। यह वह जगह है जहाँ आप रचनात्मक प्राप्त कर सकते हैं।

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

इसके अलावा, सावधानी के साथ इस सुपर पावर का उपयोग करें। 'मुझे बैनर के रंग से नफरत है, कृपया इसे बदलें' जैसी टिप्पणियां करने की कोशिश न करें।

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

काश मैं वह रचनात्मक होता! लेकिन, शायद हम सभी इसके लिए काम कर सकते हैं।

यहाँ एक बोनस है। इन बुरी आदतों को तोड़ने के लिए एक चेकलिस्ट:

१। क्या मेरा शीर्षक समस्या को स्पष्ट और संक्षिप्त रूप से व्यक्त करता है?
उदाहरण के लिए:'क्रिएट पेशेंट काम नहीं कर रहा है' एक अच्छा शीर्षक नहीं है। 'सभी इनपुट फ़ील्ड सही मान होने पर भी रोगी को विफल करें' है।

दो। प्रतिलिपि प्रस्तुत करने की दर क्या है?
दूसरे शब्दों में, क्या यह हमेशा होता है? क्या मुझे उन चरणों का सटीक अनुक्रम पता है जो समस्या को दोहराएंगे?

३। क्या यह समस्या प्लेटफ़ॉर्म, ब्राउज़र या उपयोगकर्ता विशिष्ट है?

चार। क्या चरण पूरे हो चुके हैं और आप अपने मुद्दे पर पहुँच गए हैं?

५ । क्या मेरे पास स्क्रीनशॉट शामिल है?

६। क्या मुझे किसी विशेष क्षेत्रों को उजागर करने के लिए अपने स्क्रीनशॉट को एनोटेट करने की आवश्यकता है?

।। छवि फ़ाइल का नाम वर्णनात्मक है?
कुछ का उपयोग न करें, जैसे 'Untitled.jpg।' इसे एक वर्णनात्मक नाम दें।

।। क्या मैंने परीक्षण डेटा शामिल किया था?
उदाहरण के लिए:एक व्यवस्थापक मॉड्यूल में दोष के लिए जिसे प्राधिकरण क्रेडेंशियल की आवश्यकता होती है, उन्हें शामिल करें। विकास टीम क्यूए वातावरण तक पहुंच सकती है या नहीं हो सकती है। आप किसी चीज़ में देरी नहीं करना चाहते हैं और उस पर मूल रूप से अनुवर्ती कार्रवाई करें।

९। क्या मैं अपने दोष को मजबूत करने के लिए कोई अन्य विवरण दे सकता हूं?
()उदाहरण:एफआरडी का संदर्भ या क्लाइंट के साथ बातचीत आदि)

१०। क्या मैं समझता हूं कि समस्या अलग-अलग दृष्टिकोणों से कितनी गंभीर है?

ग्यारह। क्या मुझे समस्या का मूल कारण पता है? यदि हाँ, तो क्या मेरे पास सबूत (शायद लॉग फाइलें) हैं और क्या मैं इसे शामिल कर सकता हूं? कृपया ध्यान दें कि आप इसे हमेशा नहीं जान सकते हैं या इसे जानने की आवश्यकता नहीं है। लेकिन अगर आप ऐसा करते हैं, तो इसे शामिल करने में दुख नहीं होता।

१२। क्या दोष रिपोर्ट व्याकरण, प्रारूप, वर्तनी और विराम चिह्नों से मुक्त है?

क्या एक पीसी पर dbms चलाता है

१३। क्या मुझे उत्पाद में सुधार करने का कोई तरीका पता है?

क्या आप सोच रहे हैं कि यह समय लेने वाली है? खैर, एक बार जब यह एक आदत बन जाता है, तो यह अब और नहीं होगा।

बेहतर के लिए जड़ दोष रिपोर्टिंग दिनचर्या!

लेखक के बारे में: यह लेख एसटीएच टीम की सदस्य स्वाति ने लिखा है।

नीचे अपने प्रश्नों / टिप्पणियों को बेझिझक पोस्ट करें।

अनुशंसित पाठ

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