एखादा दोष किंवा बग अहवाल लिहिणे समस्येस ओळखण्यासाठी आणि त्याचे निराकरण करण्यात बराच काळ जातो. या पोस्टमध्ये आम्ही सामान्यतया बग अहवालात समाविष्ट केलेल्या घटकांची यादी करतो.
कोणत्याही विशिष्ट क्रमानेः
अहवालातील दोष लक्षात घेण्यास सक्षम असणे अभिज्ञापक खूप महत्वाचे आहे. एखादी दोष नोंदवण्याचे साधन दोष लॉग करण्यासाठी वापरले जात असेल तर आयडी सहसा प्रोग्राम तयार केलेला अनन्य नंबर असतो जो प्रत्येक दोष लॉगमध्ये वाढ करतो.
सारांश हा दोष आणि साजरा झालेल्या अपयशाचे एकूणच उच्च स्तरीय वर्णन आहे. हा लहान सारांश दोषांचे मुख्य आकर्षण असले पाहिजे कारण विकसक किंवा पुनरावलोकनकर्त्यांनी प्रथम बग अहवालामध्ये हे पाहिले आहे.
दोषांचे स्वरूप स्पष्टपणे लिहिले जाणे आवश्यक आहे. सदोषाचा आढावा घेणारा एखादा विकसक सदोषाचा तपशील समजून घेऊ शकत नसेल किंवा त्याचे अनुसरण करू शकत नसेल तर कदाचित अधिक तपासणे व अधिक तपशील विचारणा करुन परीक्षकांकडे अहवाल परत केला जाईल ज्यामुळे समस्येचे निराकरण होण्यास विलंब होतो.
अपेक्षित निकाल काय होते आणि चाचणी चरणातील निकाल काय होता यासह दोषात पुनरुत्पादित करण्यासाठी कोणती पावले उचलली जातात या वर्णनात वर्णनात वर्णन केले पाहिजे. अपयश कोणत्या टप्प्यावर पाळले गेले हे अहवालात सांगावे.
सदोषपणाची तीव्रता अनुप्रयोग सिस्टमच्या स्वरूपावर अवलंबून इतर सिस्टम, व्यवसाय, पर्यावरण आणि लोकांच्या जीवनास हानी पोहोचविण्याच्या दृष्टीने दोष किती वेगळा आहे हे दर्शविते. तीव्रतेचे सहसा संघटनेच्या परिभाषावर अवलंबून 4 किंवा 5 पातळीमध्ये वर्गीकरण केले जाते.
एकदा तीव्रता निश्चित झाल्यानंतर, रिझोल्यूशनला कसे प्राधान्य द्यायचे ते पहावे लागेल. प्राधान्य दोष किती लवकर दुरुस्त करावे हे निर्धारित करते. प्राधान्याने साधारणपणे व्यवसायाचे महत्त्व असते जसे की प्रकल्पावर होणारा परिणाम आणि बाजारात उत्पादनाची संभाव्य यश. तीव्रतेप्रमाणेच, प्राधान्य देखील 4 किंवा 5 पातळीमध्ये वर्गीकृत केले जाते.
प्राधान्य विरूद्ध गंभीरता वर अधिक वाचा
हे लक्षात घेणे महत्वाचे आहे की ज्या दोषात तीव्रता जास्त आहे त्याला देखील उच्च प्राधान्य दिले जाते, म्हणजेच एखाद्या गंभीर दोषात शक्य तितक्या लवकर समस्येचे निराकरण करण्यासाठी उच्च प्राथमिकता आवश्यक असेल. कधीही उच्च तीव्रता आणि कमी प्राधान्य दोष असू शकत नाही. तथापि, दोषात तीव्रता कमी असू शकते परंतु त्यास जास्त प्राधान्य असू शकते.
अनुप्रयोग लॉन्च होताना कंपनीचे नाव स्प्लॅश स्क्रीनवर चुकीचे स्पेल आहे. यामुळे पर्यावरणाला किंवा लोकांच्या जीवनास गंभीर नुकसान होत नाही, परंतु कंपनीच्या प्रतिष्ठेचे संभाव्य नुकसान होऊ शकते आणि व्यवसायाच्या नफ्यास हानी पोहोचवू शकते.
तो दोष किंवा तारीख नोंदविण्याची तारीख आणि वेळ देखील आवश्यक आहे. जेव्हा आपण सॉफ्टवेअरच्या विशिष्ट रीलिझसाठी ओळखले गेलेले दोष शोधण्यासाठी किंवा चाचणी चरण कधीपासून सुरू करायचे तेव्हा हे सहसा उपयुक्त ठरते.
हे देखील खूप महत्वाचे आहे. बर्याच प्रकरणांमध्ये, सॉफ्टवेअरच्या बर्याच आवृत्त्या आहेत; प्रत्येक आवृत्तीत मागील आवृत्त्यांमध्ये बरेच निराकरणे आणि अधिक कार्यक्षमता आणि संवर्धने आहेत. म्हणूनच, आम्ही नोंदवित आहोत की सॉफ्टवेअरच्या कोणत्या आवृत्तीने अपयश दर्शविले हे लक्षात घेणे आवश्यक आहे. आम्ही अपयशी पुनरुत्पादित करण्यासाठी सॉफ्टवेअरच्या त्या आवृत्तीचा नेहमीच संदर्भ घेऊ शकतो.
पुन्हा, हे महत्वाचे आहे, कारण जर आपल्याला सदोषपणा वाढवणा to्या व्यक्तीचा संदर्भ घ्यावा लागला असेल तर कोणाशी संपर्क साधावा हे आम्हाला माहित असले पाहिजे.
मूलत :, सॉफ्टवेअर applicationप्लिकेशनची सर्व वैशिष्ट्ये संबंधित आवश्यकतांनुसार शोधली जाऊ शकतात. म्हणूनच, जेव्हा एखादी अपयश दिसून येते तेव्हा कोणत्या आवश्यकतांवर परिणाम झाला ते आपण पाहू शकतो.
हे डुप्लिकेट दोष दोष कमी करण्यास मदत करू शकेल ज्यामुळे आपण स्त्रोत आवश्यक ओळखू शकलो तर त्याच दोष क्रमांकासह एखादा दुसरा दोष लॉग झाला असेल तर दोष पुन्हा त्याच प्रकारची असल्यास आम्हाला पुन्हा अहवाल देण्याची आवश्यकता नाही.
अपयशाचे कोणतेही पुरावे कॅप्चर करून दोष अहवालासह सादर करावे. हे सदोष वर्णनाचे दृश्य स्पष्टीकरण आहे आणि पुनरावलोकनकर्त्यास, विकसकास दोष ओळखण्यास मदत करते.
या लेखात आम्ही शिकलो की आम्ही सामान्यत: बग अहवालात कोणती माहिती समाविष्ट केली पाहिजे. चांगला बग अहवाल तयार करणे बगचे मूळ कारण विश्लेषण आणि निराकरण गती देते.