उपयोगकर्ताओं को सभ्य और उपयोगी बग रिपोर्ट लिखने के लिए


32

क्या किसी को उपयोगकर्ताओं को अर्ध-सभ्य (पढ़ें: उपयोगी ) बग रिपोर्ट लिखने का एक अच्छा तरीका पता है ?

हम कुछ ऐसा करना चाहते थे जो अधिकांश उपयोगकर्ताओं के लिए समझ में आए (पढ़ने और समझने में आसान हो), फिर भी डेवलपर्स को उपयोगी जानकारी दें।

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

यह बहुत उपयोगी नहीं है, क्योंकि यह है।

मैंने एक सूची के बारे में तय करना शुरू कर दिया, लेकिन आप लोगों के साथ जांच करने के लिए सोचा, क्या एक समान विधि पहले से मौजूद है।


2
मैं प्रोग्रामरों को बंद करने के लिए मतदान को समझ सकता हूं, लेकिन ऑफटॉपिक? एक प्रोग्रामर की साइट पर बग रिपोर्ट !?
रूक

1
फर्क पड़ता है क्या? वे वैसे भी खराब बग रिपोर्ट लिखेंगे। आमतौर पर आपको उपयोगकर्ताओं को किसी भी तरह से संवाद करने की आवश्यकता होती है।
डेविड थॉर्नले

@DavidThornley - हम एक विशिष्ट उद्योग के एक प्रकार में हैं। अधिकांश उपयोगकर्ताओं के साथ मैं कभी भी कुछ महीनों बाद उन संवादों को प्राप्त नहीं करता या प्राप्त नहीं करता। मत पूछो।
रूक

3
अपने एप्लिकेशन में रिपोर्टिंग तंत्र का निर्माण करें, ताकि उपयोगकर्ता एक बटन पर क्लिक कर सके, एक टिप्पणी जोड़ सके, और एप्लिकेशन द्वारा उपयुक्त स्थिति संलग्न कर सके। "अब, कृपया उस स्थान पर क्लिक करें जहां यह गलत है" ...

3
अगर आपको जवाब मिल जाए तो मुझे बताएं। मुझे परीक्षकों से उपयोगी बग रिपोर्ट प्राप्त करने में काफी परेशानी हो रही है, उपयोगकर्ताओं को कभी भी बुरा नहीं लगता।
क्रिस्टोफ़ प्रोवोस्ट

जवाबों:


16

उपयोगकर्ताओं को सभ्य और उपयोगी बग रिपोर्ट लिखने का सबसे प्रभावी तरीका है

  1. उन्हें अपनी रिपोर्ट ऑनलाइन देखने दें ...
    [सिस्टम] रिपोर्टिंग के लिए धन्यवाद, आप अपने अनुरोध की स्थिति यहां पा सकते हैं: ...
  2. ... असाइन किए गए इंजीनियर के मूल्यांकन और टिप्पणियों के साथ ...
    [इंजीनियर] अनुरोध को अस्वीकार कर दिया गया है, निम्नलिखित विवरण गायब हैं: ...
  3. ... अपनी रिपोर्ट को संपादित / सुधारने के विकल्प के साथ ।
    [उपयोगकर्ता] आवश्यक विवरण जोड़े गए हैं, कृपया पुन: मूल्यांकन करें: ...

मैं यह दावा करना चाहूंगा कि यह एकमात्र प्रभावी तरीका है।

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

उपयोगकर्ता-संपादन योग्य ऑनलाइन बग रिपोर्ट उपयोगकर्ताओं को बेहतर सिखाने के लिए सबसे कुशल तरीका है ।

  • उपयोगकर्ताओं के साथ आमने-सामने सीखने के सत्र की व्यवस्था करने के लिए ऊपर दिए गए वैकल्पिक विकल्प 1 हैं (हां, निश्चित रूप से, जब उनमें से हजारों दुनिया भर में फैले हुए हैं)। या 2) उन्हें फोन द्वारा चीजें समझाएं ("देखो, यदि आप केवल उस बकवास को देख सकते हैं जिसे आपने लाइन 225 ..." पर लिखा था)। और क्या? ओह 3) ईमेल द्वारा, निश्चित रूप से "उस मेल में जिसे आपने दो महीने पहले हमें भेजा था, आपने उल्लेख किया है ... नहीं, वह ईमेल नहीं है, आपने हमें इस दिन पांच ईमेल भेजे थे, उनमें से तीन विषय के साथ थे : नीला बटन क्लिक करें , देखें दूसरा एक, 10Mb स्क्रीन शॉट के साथ एक यह जुड़ा हुआ है ... क्या? आप इसे नहीं ढूंढ सकते हैं? "

27

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

उदाहरण के लिए, बस उपयोगकर्ता का ईमेल प्राप्त करें, और उन्हें पूरा करने के लिए निम्नलिखित पाठ के साथ एक सादा पाठ क्षेत्र दें:

"I did _____ , and expected ______ to happen, but ______ happened instead."

ईमेल प्राप्त करने के बाद, बग को सबमिट करने की पुष्टि करने के लिए एक डबल-ऑप्ट प्राप्त करने के लिए एक ऑटो-रिप्लाई करें, जिसे आपने प्राप्त किया है, और बग पर फॉलो-अप ठीक है।


2
बहुत बढ़िया जवाब। सक्सेस एंड कम्यूनिकेटिव। मैं लोगों को समझाने के लिए इसे आगे बढ़ाना चाहता हूँ।
एरिक डाईट्रिच

यह भी टेम्प्लेट होना चाहिए जो SO प्रश्न से शुरू होता है।
कोडी पियरसाल

5
मैंने नीले बटन को दबाया , और काम करने की उम्मीद की , लेकिन इसके बजाय कुछ भी नहीं हुआ। : डी
सांगो

"मैंने _____ किया, और ______ होने की उम्मीद की, लेकिन ______ इसके बजाय हुआ।" मैं उत्पादन / क्यूए / परीक्षण वातावरण पर सॉफ्टवेयर ______ संस्करण _____ का उपयोग कर रहा था।
kubanczyk

10

आप इस विषय पर मोज़िला और सूर्य से कुछ विचार लेने पर विचार कर सकते हैं:

विशेष रूप से (मोज़िला से "एक उचित बग कैसे लिखें" पृष्ठ):

बग रिपोर्ट की सामान्य रूपरेखा

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

अच्छा : "फ़ाइल कॉपी संवाद रद्द करना फ़ाइल प्रबंधक को क्रैश करता है"

खराब : "सॉफ़्टवेयर क्रैश"

खराब : "ब्राउज़र को मेरी वेब साइट के साथ काम करना चाहिए"

घटक : यह सॉफ्टवेयर के किस उप-भाग में मौजूद है? इस क्षेत्र को किसी भी बग रिपोर्ट को प्रस्तुत करने की आवश्यकता है। प्रत्येक घटक का विवरण देखने के लिए "घटक" शब्द पर क्लिक करें। यदि कोई भी उचित नहीं लगता है, तो "सामान्य" घटक को उजागर करें।

OS : किस ऑपरेटिंग सिस्टम (OS) पर आपने इसे पाया? (जैसे लिनक्स, विंडोज एक्सपी, मैक ओएस एक्स।) उदाहरण: "यदि आपको पता है कि बग एक से अधिक प्रकार के ऑपरेटिंग सिस्टम पर होता है, तो" ऑल "चुनें।" यदि आपका OS सूचीबद्ध नहीं है, तो अन्य चुनें।

विवरण : सहित आपकी समस्या रिपोर्ट का विवरण:

- अवलोकन : यह सारांश का एक बड़ा विस्तृत विवरण है। एक उदाहरण होगा: "NSGetFactory फंक्शन में मैक बनाने वाले किसी भी पेज को ड्रैग-सेलेक्ट करना"।

- बिल्ड आईडी : इसे खोजने के लिए या तो स्थान पट्टी के माध्यम से "के बारे में:" पृष्ठ पर जाएं या यदि आपके पास मोज़ेक के नाइटली परीक्षक उपकरण एक्सटेंशन है, तो टूल पर जाएं। रात में परीक्षक उपकरण और उस विकल्प का चयन करें जिसमें बिल्ड आईडी का आउटपुट है। यह कुछ इस तरह दिखना चाहिए: "मोज़िला / 5.0 (मैकिन्टोश; यू; इंटेल मैक ओएस एक्स 10.5; एन-यूएस; आरवी: 1.9.1 बी 3) गेको / 20090305 फ़ायरफ़ॉक्स / 3.1 बी 3 ″।

- अतिरिक्त बिल्ड और प्लेटफ़ॉर्म : बग अन्य प्लेटफार्मों (या ब्राउज़र, यदि लागू हो) पर होता है या नहीं। इसे कुछ इस तरह से देखना चाहिए: "मोज़िला / 5.0 (Macintosh; U; इंटेल मैक OS X 10.5; en-US; rv: 1.9.1b3) गेको / 20081107 फ़ायरफ़ॉक्स / 3.1b2 this पर ऐसा नहीं होता।

रीप्रोड्यूस करने के लिए कदम : मिनिमाइज्ड, आसान-से-स्टेप्स, जो बग को ट्रिगर करेंगे। यदि वे आवश्यक हों, तो कोई भी विशेष सेटअप चरण शामिल करना सुनिश्चित करें। इसका अच्छा उदाहरण निम्नलिखित होगा: 1) किसी भी वेब पेज को देखें। (मैंने डिफ़ॉल्ट नमूना पृष्ठ, http://www.google.com/ का उपयोग किया )। 2) पेज को ड्रैग-सलेक्ट करें। विशेष रूप से, माउस बटन को दबाए रखते समय, माउस पॉइंटर को ब्राउज़र के सामग्री क्षेत्र में किसी भी बिंदु से ब्राउज़र के सामग्री क्षेत्र के नीचे तक खींचें।

वास्तविक परिणाम : उपरोक्त चरणों को पूरा करने के बाद आवेदन ने क्या किया। एक उदाहरण होगा: आवेदन दुर्घटनाग्रस्त हो गया।

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


10
मुझे सच में समझ नहीं आ रहा है कि इसे इतने वोट क्यों मिले। सवाल यह नहीं है कि "एक सभ्य बग रिपोर्ट कैसे लिखें?" लेकिन " उपयोगकर्ताओं को एक सभ्य बग रिपोर्ट लिखने के लिए कैसे प्राप्त करें "।
तमसे सजेलेई

8
वे संसाधन ज्यादातर तकनीकी लोगों पर लक्षित होते हैं। इसके अलावा मोज़िला वह संगठन है जिसने हमें बुगज़िला लाया। मैं यह नहीं कह रहा हूँ कि बगजिला बुरा है, लेकिन इसे बनाया गया है द्वारा इंजीनियरों के लिए इंजीनियरों: यह वास्तव में एक अंतिम-उपयोगकर्ता उपकरण नहीं है सब पर
जोकिम सॉयर

3
@Fish से सहमत होना होगा। हम अपने परीक्षकों को दुनिया में सभी दिशा-निर्देश दे सकते हैं - जिससे वे वास्तव में उपयोगी बग रिपोर्ट नहीं बना सकते हैं । और मैं उन लोगों के बारे में बात कर रहा हूं जो बग्स की रिपोर्ट करना चाहते हैं - अगर हम उन्हें उन दिशानिर्देशों के साथ प्रेरित नहीं कर सकते हैं जिन्हें हमें वास्तविक उपयोगकर्ताओं के साथ बिल्कुल भी आशा नहीं है। केवल एक चीज जो हमें प्रभावी लगी, वह "बेकार" बग रिपोर्ट को "पर्याप्त जानकारी नहीं" के रूप में सक्रिय रूप से बंद कर रही थी - उन्हें संदेश बहुत जल्दी मिला। मैं बाहरी उपयोगकर्ताओं के लिए इसकी सलाह नहीं देता, हालांकि :-)
HappyCat

3
मैं बिल्कुल (बहुत अच्छे संसाधनों पर पोस्ट की उपयोगिता पर बहस कर रहा हूं, वास्तव में) लेकिन यह सवाल का जवाब नहीं देता है, और मुझे लगता है कि मतदान नीति उस पर आधारित है (मैं गलत हो सकता है)।
तमसे सजेलेई

1
मैं इस तरह के व्यक्ति का उद्देश्य था और यहां तक ​​कि मैं पूरी बात पढ़ने के माध्यम से बैठ नहीं सकता था। आपको क्या लगता है कि उपयोगकर्ता क्या करने जा रहे हैं?
टैक्रॉय

4

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


4

आप उपयोगी रिपोर्ट की उम्मीद करने के लिए उपयोगकर्ताओं को सवालों के जवाब देने के लिए समझने में आसान और आसान पूछ सकते हैं।

उदाहरण के लिए, "इस त्रुटि से पहले आपकी अंतिम क्रिया क्या थी?", "क्या आपने इस त्रुटि के ठीक पहले ... की कोशिश की थी?"।

कोई भी उपयोगकर्ता आपको बग रिपोर्ट नहीं लिखेगा, जैसे: "मेरा वीडियो ड्राइवर अपटूडेट नहीं है। आपकी ग्राफिक्स लाइब्रेरी पुराने ग्राफिक ड्राइवरों के अनुकूल नहीं हो सकती है।"


3

उपयोगकर्ता आधार मान लें कि आपके द्वारा लिखे गए सॉफ़्टवेयर के साथ समस्या वाले उपयोगकर्ता हैं ...।

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

अर्थात यह उनका काम नहीं है .....

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


1
मुझे नहीं लगता कि ओपी कह रहा है कि वे उपयोगकर्ताओं के साथ व्यवहार नहीं करना चाहते हैं। मुझे लगता है कि ओपी कह रहा है कि वे बग रिपोर्ट 'यह दुर्घटनाग्रस्त' के आधार पर वास्तव में कुछ भी ठीक नहीं कर सकते हैं। ओपी शिकायत करने वाले उपयोगकर्ताओं में से सबसे अधिक पाने का एक तरीका चाहता है, ताकि ओपी वास्तव में समस्या को ठीक कर सके।
माइकल कोहेन

1
मेरा कहना है कि अगर "यह दुर्घटनाग्रस्त हो गया" तो उपयोगकर्ता के दृष्टिकोण से क्या होता है। जब मैं अपनी कार को एक मैकेनिक के पास ले जाता हूं, तो वह मुझसे यह उम्मीद नहीं करता है कि जो गलत है, उसकी एक विशेषज्ञ विस्तृत नैदानिक ​​रिपोर्ट आपको दे - वह मुझसे सवाल पूछता है कि समस्या का निदान करने के लिए अपनी विशेषज्ञता का उपयोग करने में उसकी मदद करें। उदाहरण के लिए, मेरी समस्या यह थी कि "यह ठंडा होने पर स्टॉल करता है, लेकिन ठीक है जब इसके गर्म होने पर", कुछ अच्छी तरह से विचार किए जाने वाले प्रश्न (हाँ नहीं उत्तरों के साथ) बाद में वह काफी निश्चित था (और सही निकला) यह एक दोषपूर्ण था थर्मामीटर। हमारा काम सवाल पूछना है, हां नहीं जवाब देने के लिए तैयार किया गया है।
मटनज
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.