बग अहवालात काय समाविष्ट करावे?

चांगला बग अहवाल कसा लिहावा

एखादा दोष किंवा बग अहवाल लिहिणे समस्येस ओळखण्यासाठी आणि त्याचे निराकरण करण्यात बराच काळ जातो. या पोस्टमध्ये आम्ही सामान्यतया बग अहवालात समाविष्ट केलेल्या घटकांची यादी करतो.

कोणत्याही विशिष्ट क्रमानेः

दोष ओळखकर्ता, आयडी

अहवालातील दोष लक्षात घेण्यास सक्षम असणे अभिज्ञापक खूप महत्वाचे आहे. एखादी दोष नोंदवण्याचे साधन दोष लॉग करण्यासाठी वापरले जात असेल तर आयडी सहसा प्रोग्राम तयार केलेला अनन्य नंबर असतो जो प्रत्येक दोष लॉगमध्ये वाढ करतो.

सारांश

सारांश हा दोष आणि साजरा झालेल्या अपयशाचे एकूणच उच्च स्तरीय वर्णन आहे. हा लहान सारांश दोषांचे मुख्य आकर्षण असले पाहिजे कारण विकसक किंवा पुनरावलोकनकर्त्यांनी प्रथम बग अहवालामध्ये हे पाहिले आहे.

वर्णन

दोषांचे स्वरूप स्पष्टपणे लिहिले जाणे आवश्यक आहे. सदोषाचा आढावा घेणारा एखादा विकसक सदोषाचा तपशील समजून घेऊ शकत नसेल किंवा त्याचे अनुसरण करू शकत नसेल तर कदाचित अधिक तपासणे व अधिक तपशील विचारणा करुन परीक्षकांकडे अहवाल परत केला जाईल ज्यामुळे समस्येचे निराकरण होण्यास विलंब होतो.

अपेक्षित निकाल काय होते आणि चाचणी चरणातील निकाल काय होता यासह दोषात पुनरुत्पादित करण्यासाठी कोणती पावले उचलली जातात या वर्णनात वर्णनात वर्णन केले पाहिजे. अपयश कोणत्या टप्प्यावर पाळले गेले हे अहवालात सांगावे.



तीव्रता

सदोषपणाची तीव्रता अनुप्रयोग सिस्टमच्या स्वरूपावर अवलंबून इतर सिस्टम, व्यवसाय, पर्यावरण आणि लोकांच्या जीवनास हानी पोहोचविण्याच्या दृष्टीने दोष किती वेगळा आहे हे दर्शविते. तीव्रतेचे सहसा संघटनेच्या परिभाषावर अवलंबून 4 किंवा 5 पातळीमध्ये वर्गीकरण केले जाते.

  • एस 1 - गंभीरः याचा अर्थ हा दोष हा उच्च संभाव्य हानीसह शो स्टॉपर आहे आणि सदोषपणा टाळण्यासाठी कसरत नाही. Allप्लिकेशन मुळीच सुरू होत नाही आणि ऑपरेटिंग सिस्टम बंद होण्यास कारणीभूत असू शकते याचे एक उदाहरण असू शकते. यासाठी त्वरित लक्ष आणि कृती आणि निराकरण आवश्यक आहे.
  • एस 2 - गंभीरः याचा अर्थ असा आहे की अनुप्रयोगांची काही प्रमुख कार्ये एकतर गहाळ आहेत किंवा कार्य करत नाहीत आणि कोणतेही कसरतही नाही. उदाहरण, प्रतिमा पाहणारा अनुप्रयोग काही सामान्य प्रतिमा स्वरूप वाचू शकत नाही.
  • एस 3 - सामान्य: याचा अर्थ असा आहे की काही प्रमुख कार्यक्षमता कार्य करत नाहीत, परंतु तात्पुरता उपाय म्हणून वापरण्यासाठी एक कार्यपद्धती विद्यमान आहे.
  • एस 4 - कॉस्मेटिक / संवर्धन: याचा अर्थ असा की अपयशामुळे असुविधा व त्रास होतो. उदाहरण असू शकते की दर 15 मिनिटांत एक पॉप-अप संदेश आहे किंवा आपण नेहमी जीयूआय बटणावर दोनदा क्लिक करावे लागेल क्रिया करण्यासाठी.
  • एस 5 - सूचना: कार्यक्षमता सुधारण्यासाठी ही सामान्यत: दोष आणि सूचना नसते. हे जीयूआय किंवा पहात प्राधान्ये असू शकतात.

प्राधान्य

एकदा तीव्रता निश्चित झाल्यानंतर, रिझोल्यूशनला कसे प्राधान्य द्यायचे ते पहावे लागेल. प्राधान्य दोष किती लवकर दुरुस्त करावे हे निर्धारित करते. प्राधान्याने साधारणपणे व्यवसायाचे महत्त्व असते जसे की प्रकल्पावर होणारा परिणाम आणि बाजारात उत्पादनाची संभाव्य यश. तीव्रतेप्रमाणेच, प्राधान्य देखील 4 किंवा 5 पातळीमध्ये वर्गीकृत केले जाते.

  • पी 1 - तातडीचा: म्हणजे अत्यंत निकड आणि त्वरित निराकरणाची आवश्यकता आहे
  • पी 2 - उच्च: पुढील बाह्य रीलिझसाठी निराकरण आवश्यक आहे
  • पी 3 - मध्यम: प्रथम उपयोजनासाठी ठराव आवश्यक आहे (सर्व उपयोजनांपेक्षा)
  • पी 4 - कमीः प्रथम उपयोजन किंवा त्यानंतरच्या प्रकाशनांसाठी रिझोल्यूशन इच्छित

प्राधान्य विरूद्ध गंभीरता वर अधिक वाचा

हे लक्षात घेणे महत्वाचे आहे की ज्या दोषात तीव्रता जास्त आहे त्याला देखील उच्च प्राधान्य दिले जाते, म्हणजेच एखाद्या गंभीर दोषात शक्य तितक्या लवकर समस्येचे निराकरण करण्यासाठी उच्च प्राथमिकता आवश्यक असेल. कधीही उच्च तीव्रता आणि कमी प्राधान्य दोष असू शकत नाही. तथापि, दोषात तीव्रता कमी असू शकते परंतु त्यास जास्त प्राधान्य असू शकते.

अनुप्रयोग लॉन्च होताना कंपनीचे नाव स्प्लॅश स्क्रीनवर चुकीचे स्पेल आहे. यामुळे पर्यावरणाला किंवा लोकांच्या जीवनास गंभीर नुकसान होत नाही, परंतु कंपनीच्या प्रतिष्ठेचे संभाव्य नुकसान होऊ शकते आणि व्यवसायाच्या नफ्यास हानी पोहोचवू शकते.

तारीख आणि वेळ

तो दोष किंवा तारीख नोंदविण्याची तारीख आणि वेळ देखील आवश्यक आहे. जेव्हा आपण सॉफ्टवेअरच्या विशिष्ट रीलिझसाठी ओळखले गेलेले दोष शोधण्यासाठी किंवा चाचणी चरण कधीपासून सुरू करायचे तेव्हा हे सहसा उपयुक्त ठरते.

चाचणी अंतर्गत सॉफ्टवेअरची आवृत्ती आणि बिल्ड

हे देखील खूप महत्वाचे आहे. बर्‍याच प्रकरणांमध्ये, सॉफ्टवेअरच्या बर्‍याच आवृत्त्या आहेत; प्रत्येक आवृत्तीत मागील आवृत्त्यांमध्ये बरेच निराकरणे आणि अधिक कार्यक्षमता आणि संवर्धने आहेत. म्हणूनच, आम्ही नोंदवित आहोत की सॉफ्टवेअरच्या कोणत्या आवृत्तीने अपयश दर्शविले हे लक्षात घेणे आवश्यक आहे. आम्ही अपयशी पुनरुत्पादित करण्यासाठी सॉफ्टवेअरच्या त्या आवृत्तीचा नेहमीच संदर्भ घेऊ शकतो.

यांनी नोंदवले

पुन्हा, हे महत्वाचे आहे, कारण जर आपल्याला सदोषपणा वाढवणा to्या व्यक्तीचा संदर्भ घ्यावा लागला असेल तर कोणाशी संपर्क साधावा हे आम्हाला माहित असले पाहिजे.

संबंधित आवश्यकता

मूलत :, सॉफ्टवेअर applicationप्लिकेशनची सर्व वैशिष्ट्ये संबंधित आवश्यकतांनुसार शोधली जाऊ शकतात. म्हणूनच, जेव्हा एखादी अपयश दिसून येते तेव्हा कोणत्या आवश्यकतांवर परिणाम झाला ते आपण पाहू शकतो.

हे डुप्लिकेट दोष दोष कमी करण्यास मदत करू शकेल ज्यामुळे आपण स्त्रोत आवश्यक ओळखू शकलो तर त्याच दोष क्रमांकासह एखादा दुसरा दोष लॉग झाला असेल तर दोष पुन्हा त्याच प्रकारची असल्यास आम्हाला पुन्हा अहवाल देण्याची आवश्यकता नाही.

संलग्नक / पुरावा

अपयशाचे कोणतेही पुरावे कॅप्चर करून दोष अहवालासह सादर करावे. हे सदोष वर्णनाचे दृश्य स्पष्टीकरण आहे आणि पुनरावलोकनकर्त्यास, विकसकास दोष ओळखण्यास मदत करते.

निष्कर्ष

या लेखात आम्ही शिकलो की आम्ही सामान्यत: बग अहवालात कोणती माहिती समाविष्ट केली पाहिजे. चांगला बग अहवाल तयार करणे बगचे मूळ कारण विश्लेषण आणि निराकरण गती देते.