art bug reporting
मार्केटिंग बग की आवश्यकता क्यों है?
इस लेख को लिखना शुरू करते ही मेरे दिमाग में सबसे पहली बातें आती हैं केम कनेर - 'सबसे अच्छा परीक्षक वह नहीं है जो सबसे अधिक बग पाता है या जो अधिकांश प्रोग्रामर को शर्मिंदा करता है। सबसे अच्छा परीक्षक वह होता है जो सबसे अधिक कीड़े को ठीक करता है। '
अब - क्या अंतर है अधिकांश बग ढूंढना तथा अधिकांश बग्स को ठीक करना ?
क्या यह स्पष्ट नहीं है कि कोई बग लॉग इन किया है बग प्रबंधन प्रणाली डेवलपर द्वारा तय किया जाना चाहिए? इसका उत्तर है, उत्पाद के विपणन के लिए समय जैसे कारक, समय पर परियोजना को पूरा करने के लिए समय और डेवलपर्स में काम करना अव्यवहारिक तंग कार्यक्रम आदि कंपनियों को कुछ बग्स के साथ उत्पाद जारी करने के लिए मजबूर करते हैं जो उपयोगकर्ताओं को बड़े पैमाने पर प्रभावित नहीं करते हैं।
(छवि स्रोत )
प्रबंधन मी को यह विश्वास दिलाता है कि उत्पाद में मौजूद कीड़े ग्राहक के विश्वास, विश्वसनीयता और हितधारकों के हित को प्रभावित नहीं करेंगे? - परीक्षण अभियंता या परीक्षण दल - यह प्रत्येक परीक्षण इंजीनियर का कर्तव्य है कि वे बग्स को ठीक करें जो उत्पाद की गुणवत्ता पर नकारात्मक प्रभाव डाल सकते हैं।
बग की प्राथमिकता , मेरी राय में, काफी हद तक इस बात पर निर्भर करता है कि टेस्टर द्वारा विकास और प्रबंधन टीमों को एक मुद्दा कैसे प्रस्तुत किया जाता है।
इसे विज्ञापन की तरह समझें या मुद्दे की मार्केटिंग करें - इसमें 2 चरण शामिल हैं:
- लिखें या बग्स की सही रिपोर्ट करें
- बग के बारे में सब कुछ पता है, इसलिए किसी भी आगे के विवरण को बेहतर तरीके से समझाया जा सकता है
आप क्या सीखेंगे:
- बग रिपोर्टिंग की कला
- सॉफ्टवेयर संस्करण नियंत्रण बैठकों में कुशल भागीदारी
- बग को ठीक से विपणन नहीं करने का प्रभाव
- निष्कर्ष
- अनुशंसित पाठ
बग रिपोर्टिंग की कला
हाँ, बग रिपोर्टिंग एक कला है । जिस तरह से एक बग लिखा जाता है वह एक परीक्षण इंजीनियर की तकनीकी कौशल, डोमेन विशेषज्ञता और संचार क्षमताओं को दर्शाता है।
आमतौर पर, बग में निम्नलिखित जानकारी होनी चाहिए:
- बग सारांश
- प्रजनन के चरण
- अनुलग्नक (स्नैपशॉट, लॉग फ़ाइलें आदि)
- बग प्रजनन
- बग गंभीरता
- सॉफ्टवेयर संस्करण, पर्यावरण सूचना
- संगठनात्मक आवश्यकताओं के आधार पर अन्य जानकारी।
एक महत्वपूर्ण नोट: समस्या के मूल कारण का पता लगाने और इसकी रिपोर्ट करने के लिए हमेशा गहरी खुदाई करें। उदाहरण के लिए, उपयोगकर्ता नाम और पासवर्ड के सही संयोजन के साथ एक सरल लॉगिन विफलता विभिन्न कारणों से संबंधित हो सकती है जैसे:
- लॉगिन क्रेडेंशियल बिल्कुल भी मान्य नहीं हैं
- दूरस्थ लॉगिन के मामले में नेटवर्क टाइमआउट समस्याएँ
- सिस्टम सभी CAPS को गैर-CAPS मान सकता है।
इसलिए, एक परीक्षक के रूप में आपको बग सारांश कथनों का पालन करते हुए मतभेदों को समझने में सक्षम होना चाहिए:
- 'सही उपयोगकर्ता नाम और पासवर्ड के साथ लॉग इन करने में असमर्थ'
- 'सही उपयोगकर्ता नाम और पासवर्ड के साथ लॉग इन करने में असमर्थ, जब उपयोगकर्ता नाम या पासवर्ड में CAPS और गैर-कैप अल्फ़ाज़ का मिश्रण होता है।'
उत्तरार्द्ध समस्या का बहुत स्पष्ट वर्णन है और असंदिग्ध है। इसके साथ, आप न केवल एक परीक्षक के रूप में अपनी विश्वसनीयता बढ़ाते हैं, बल्कि आप एक लक्षण के बजाय वास्तविक समस्या की रिपोर्ट कर रहे हैं।
अब, बग रिपोर्ट में शामिल प्रत्येक क्षेत्र पर एक नज़र डालते हैं और हर एक के महत्वपूर्ण पहलुओं पर चर्चा करते हैं:
# 1 बग सारांश
एक बग सारांश वास्तव में समस्या क्या है की एक त्वरित स्नैपशॉट प्रदान करना चाहिए। यह सटीक और अच्छी तरह से निर्देशित किया जाना है।
उदाहरण :
सिद्धांत के अलावा, मैं उदाहरणों के साथ समझाने की कोशिश करूंगा।
मान लें कि एक साधारण लॉगिन मॉड्यूल है। इस बात को मान लें कि एक वेबसाइट पर आने वाले नए उपयोगकर्ता अपने डिफ़ॉल्ट पासवर्ड के साथ लॉगिन करने में असमर्थ है। जब मैंने प्रशिक्षण के प्रारंभिक चरण के दौरान जिन छात्रों को प्रशिक्षित किया, उनमें से कई के लिए मैंने ऐसा ही परिदृश्य प्रस्तुत किया, तो बग सारांश के रूप में कई उत्तर थे। नीचे कुछ नमूने दिए गए हैं कि सारांश कैसा दिखता है:
परीक्षण के मामले और परीक्षण परिदृश्य के बीच अंतर
' नया उपयोगकर्ता लॉगिन करने में असमर्थ है ”
'उपयोगकर्ता लॉगिन उम्मीद के मुताबिक काम नहीं कर रहा है'
'उपयोगकर्ता सही पासवर्ड के साथ लॉगिन करने में असमर्थ है'
उपरोक्त नमूनों से, क्या आप एक बयान दे सकते हैं जो वास्तव में समस्या का वर्णन करता है? मुझे ऐसा नहीं लगता। सारांश को हमेशा असफल परिदृश्य के बारे में पूरी जानकारी देनी चाहिए।
निम्नलिखित कथन पर विचार करें:
'नया उपयोगकर्ता ई-मेल या एसएमएस के माध्यम से दिए गए डिफ़ॉल्ट पासवर्ड के साथ लॉगिन करने में असमर्थ है'
जैसा कि आप देख सकते हैं, उपरोक्त कथन से एक डेवलपर स्पष्ट रूप से समझ सकता है कि मुद्दा क्या है और मुद्दा कहां है।
इसलिए, सारांश का वर्णन करने के लिए सही शब्दों को खोजने का प्रयास करें जो सीधे जानकारी देंगे। सामान्य कथन जैसे 'ठीक से काम नहीं करना', 'अपेक्षित रूप से काम न करना' आदि से बचना चाहिए।
# २। प्रत्यावर्तन और संलग्नक के लिए कदम
इररेप्रोडयूसीबल बग हमेशा पीछे की सीट लेते हैं, भले ही वे महत्वपूर्ण हों। इसलिए, सही और वर्णनात्मक रूप से चरणों को लिखने के लिए अच्छी देखभाल करें।
कदम सटीक और ठीक उसी तरह होने चाहिए, जिस तरह से समस्या पैदा हुई। कार्यक्षमता से संबंधित बग के लिए, निम्न नमूना सबसे अच्छा उदाहरण है।
उदाहरण :
पिछले भाग में बताए गए एक ही मुद्दे पर विचार करें।
- होम पेज में साइन अप विकल्प का उपयोग करके एक नया उपयोगकर्ता बनाएं। (नमूना यूजर का नाम: HelloUser)
- डिफ़ॉल्ट पासवर्ड के साथ एक ई-मेल और एक एसएमएस प्राप्त होगा। उपयोगकर्ता को चरण # 1 में बनाते समय एसएमएस के लिए ई-मेल आईडी और मोबाइल नंबर प्रदान किया जाता है। (नमूना ई-मेल: HelloUser@hello.com , नमूना मोबाइल नंबर: 444-222-1123)
- होम पेज में लॉगइन विकल्प चुनें।
- उपयोगकर्ता नाम पाठ क्षेत्र में, चरण # 1 में प्रदान नमूना उपयोगकर्ता नाम प्रदान करें।
- पासवर्ड फ़ील्ड में, ई-मेल या एसएमएस के माध्यम से प्राप्त डिफ़ॉल्ट पासवर्ड प्रदान करें।
- साइन इन बटन पर क्लिक करें
- अपेक्षित परिणाम: उपयोगकर्ता को दिए गए उपयोगकर्ता नाम और पासवर्ड के साथ लॉगिन करने और उपयोगकर्ता खाता पृष्ठ पर नेविगेट करने में सक्षम होना चाहिए।
- वास्तविक परिणाम: 'अमान्य उपयोगकर्ता नाम / पासवर्ड' संदेश प्रदर्शित होता है।
यदि कोई जानकारी, उपरोक्त नमूने में प्रदान नहीं की गई है, तो यह होगा संचार अंतराल में परिणाम और डेवलपर समस्या को पुन: उत्पन्न करने में सक्षम नहीं होगा। परीक्षण के दौरान आपके द्वारा उपयोग किए गए नमूना डेटा के साथ चरणों को विशिष्ट और विस्तृत करना होगा।
यदि संभव हो या जहां भी लागू हो, एक प्रदान करें स्नैपशॉट क्या आप वास्तव में स्क्रीन पर देखते हैं। इस तरह, यह न केवल डेवलपर्स को मुद्दे का एक अच्छा दृश्य प्रदान करेगा, बल्कि आपके परीक्षा परिणाम का एक प्रमाण भी होगा।
गैर कार्यात्मक उपरोक्त विवरणों के अलावा तनाव, स्थिरता या प्रदर्शन परीक्षण मामलों जैसे परीक्षण मामलों, उस स्थिति के बारे में जानकारी जो सिस्टम को तनाव का कारण बनता है, जैसा कि बताया जा सकता है। इसके अतिरिक्त, कुछ प्रणालियाँ हैं जो रिपोर्ट किए गए प्रत्येक ऑपरेशन के लिए लॉग की रिपोर्ट करती हैं। लॉग आमतौर पर डेवलपर्स द्वारा उनके कोड में दिए गए प्रिंट स्टेटमेंट होते हैं। जब भी किसी मॉड्यूल को निष्पादित किया जाता है तो संबंधित लॉग मुद्रित या प्रदर्शित किए जाएंगे। जब लॉग उपलब्ध होते हैं, तो डेवलपर्स को समस्या को पुन: पेश करने में काफी हद तक मदद मिलेगी।
# 3 बग रिप्रोड्यूसबिलिटी
एक मुद्दा जो बड़ा या छोटा होता है, उसे पुनरुत्पत्ति के आधार पर प्राथमिकता दी जाएगी। यह हमेशा, कभी-कभी, कभी-कभी या केवल एक बार भी देखा जा सकता है। एक मुद्दा जो 'हमेशा' के रूप में पुन: पेश किया जाता है, उसे बाकी की तुलना में अधिक प्राथमिकता दी जाएगी।
इसलिए, परीक्षण इंजीनियर का यह कर्तव्य है कि वह हमेशा जारी रहने वाले मुद्दे के लिए परिदृश्य को ट्रैक करे। कभी-कभी एक परीक्षण इंजीनियर के नियंत्रण से बाहर कुछ समस्याएं हो सकती हैं जिसके परिणामस्वरूप एक मुद्दा केवल कुछ ही बार लेकिन कई परीक्षणों में पुन: पेश किया जाएगा। ऐसे मामलों में, हमेशा परीक्षणों की संख्या का उल्लेख करें, उन परीक्षणों के दौरान समस्या को देखे जाने की संख्या के साथ एक विशेष परिदृश्य निष्पादित किया जाता है।
यह बदले में, आपके द्वारा उल्लिखित बग रिपोर्ट में विश्वसनीयता जोड़ देगा। फिर से, यह एक परीक्षक के रूप में आपकी प्रतिष्ठा में सुधार करेगा। मैं बाद में आपको एक अच्छी प्रतिष्ठा होने के कारण बताता हूँ।
# 4 बग गंभीरता
बग को प्राथमिकता देने के लिए गंभीरता निस्संदेह सबसे बड़े प्रभावों में से एक है।
निम्नलिखित गंभीरता की विभिन्न श्रेणियां हैं। कृपया ध्यान दें कि ये केवल सामान्य नमूने हैं और यह कंपनी से कंपनी में भिन्न होता है।
- गंभीर 1 - शो स्टॉपर - उन बगों के लिए, जो विनाशकारी हैं, बिना तय किए उपयोगकर्ता को सॉफ्टवेयर का उपयोग करना जारी रखने में सक्षम नहीं होगा और कोई संभव समाधान नहीं है
- गंभीरता 2 - उच्च - गंभीरता 1 के समान बग के लिए, लेकिन एक वर्कअराउंड है
- गंभीरता 3 - मध्यम
- गंभीरता 4 - कम
- गंभीरता 5 - तुच्छ।
उदाहरण के लिए, दो समान मुद्दों की तुलना करते हैं।
हमारे सेट-टॉप बॉक्स में, कुछ सेवा प्रदाता वर्तमान में ट्यून की गई सेवा की आवृत्ति जानकारी प्रदान करते हैं। मान लें कि आवृत्ति 100.20 मेगाहर्ट्ज के बजाय 100 मेगाहर्ट्ज के रूप में प्रदर्शित होती है। यह सेवाओं के उपयोगकर्ता के देखने को प्रभावित नहीं कर सकता है, लेकिन सेट-टॉप के निदान की निगरानी के मामले में प्रभावित हो सकता है। इसलिए इसे गंभीरता 3 मुद्दे के रूप में प्रस्तुत किया जा सकता है।
बैंकिंग डोमेन में एक समान मुद्दे को मानते हुए: यदि आपके खाते का शेष $ 100.20 के बजाय $ 100 के रूप में प्रदर्शित होता है, तो मुद्दे के प्रभाव की कल्पना करें। यह एक गंभीरता -1 दोष होना चाहिए। जैसा कि आप दोनों मामलों में देख सकते हैं कि यह समस्या बहुत समान है कि UI दशमलव बिंदु के बाद अंकों को प्रदर्शित नहीं कर रहा है। लेकिन, इसमें शामिल डोमेन के अनुसार प्रभाव भिन्न होता है।
सॉफ्टवेयर संस्करण नियंत्रण बैठकों में कुशल भागीदारी
आमतौर पर, बग्स की जांच और प्राथमिकता देने के लिए हर संगठन की अपनी प्रक्रिया होती है। आम तौर पर, कीड़े पर चर्चा करने और उसी को प्राथमिकता देने के लिए परियोजना के दौरान विशिष्ट अंतराल पर एक बैठक होती है।
इस तरह की बैठकों के दौरान प्रक्रिया इस प्रकार है:
- गंभीरता के अनुसार बग प्रबंधन प्रणाली से कीड़े की सूची को क्वेरी करें।
- सारांश देखें और सॉफ़्टवेयर उत्पाद का उपयोग करने पर उपयोगकर्ता के अनुभव पर बग के प्रभाव पर चर्चा करें।
- जोखिम और प्रभाव के आकलन के आधार पर प्राथमिकता निर्धारित करते हैं और बग को ठीक करने के लिए एक उपयुक्त डेवलपर को असाइन करते हैं।
चरण # 2 के दौरान, यह आवश्यक है कि प्रत्येक परीक्षण इंजीनियर बग के उपयोगकर्ता अनुभव पर बग के प्रभाव की वकालत करता है यदि बग को वह प्राथमिकता नहीं मिलती है जिसके वह हकदार है। आखिरकार, यह हम परीक्षण इंजीनियर हैं जो परीक्षण मामलों को लिखने और उत्पाद का परीक्षण करने के लिए एक उपयोगकर्ता के दृष्टिकोण पर विचार करते हैं।
बैंकिंग क्षेत्र में दशमलव बिंदु के बाद अंक प्रदर्शित नहीं करने के उपरोक्त उदाहरण के मुद्दे पर विचार करें। एक डेवलपर के लिए, यह कम गंभीर मुद्दे की तरह लग सकता है। वह तर्क दे सकता है कि चर को पूर्णांक के रूप में घोषित करने के बजाय, उन्होंने घोषणा की कि समस्या को हल करने के लिए एक अस्थायी बिंदु के रूप में और इसलिए कम गंभीर है।
लेकिन एक परीक्षक के रूप में, आपकी भूमिका ग्राहक की स्थिति को समझा रही है। आपकी बात यह होनी चाहिए कि उपयोगकर्ता इस परिदृश्य में कैसे शिकायत करेगा। परीक्षक को यह कहना चाहिए कि इससे उपयोगकर्ताओं में घबराहट होगी क्योंकि ग्राहक सेंट में अपना पैसा खो देता है।
बग को ठीक से विपणन नहीं करने का प्रभाव
यदि बग को ठीक से विपणन नहीं किया जाता है, तो यह समस्या पैदा करेगा:
- गलत दोष प्राथमिकता
- महत्वपूर्ण मुद्दों को हल करने में देरी
- गंभीर दोषों के साथ उत्पाद रिलीज
- नकारात्मक ग्राहक प्रतिक्रिया
- ब्रांड वैल्यू का मूल्यांकन करना
उपरोक्त सभी कारणों के अलावा, आपका निर्माण करना बहुत महत्वपूर्ण है एक परीक्षण इंजीनियर के रूप में प्रतिष्ठा । यह अपने स्वयं के लिए एक ब्रांड मूल्य विकसित करने की तरह है।
अपने करियर के शुरुआती चरण में, यदि आप 'नॉट रेप्रोड्यूस' या 'नीड मोर इंफॉर्मेशन' या 'नॉट वेलिड बग' की अपनी संख्या रख सकते हैं या जितनी संभव हो उतनी गंभीरता में परिवर्तन कर सकते हैं, तो एक स्तर पर आपके बग की जांच नहीं की जाएगी। बिल्कुल भी और वे सीधे तय किए जाने वाले उपयुक्त डेवलपर को सौंपे जाएंगे।
ऐसे ब्रांड मूल्य को विकसित करने और अपनी टीम और विकास / या प्रबंधन टीमों का विश्वास जीतने के लिए, आप ज्ञान, डोमेन और संचार कौशल के परीक्षण के संदर्भ में कुछ तकनीकी कौशल विकसित करना चाहते हैं।
निष्कर्ष
कोई भी उत्पाद या सेवा या तो बड़ा या छोटा हमेशा उचित विज्ञापन के बिना विफल होने के लिए बाध्य है। एक बार एक ब्रांड स्थापित हो जाने के बाद, कोई भी छोटा उत्पाद दर्शकों के साथ सुपर हिट हो सकता है।
यह कहने के बाद कि, किसी उत्पाद के विज्ञापन से भी प्रतिष्ठा को नुकसान हो सकता है।
इसलिए, बग को हमेशा स्पष्ट, संक्षिप्त और सटीक तरीके से लिखा जाना चाहिए ताकि यह विस्तृत / संपूर्ण सॉफ्टवेयर मैप में बग का सटीक स्थान दे सके। मैं इस बात को दोहराता हूं कि इससे न केवल सॉफ्टवेयर की गुणवत्ता में सुधार होता है, बल्कि सॉफ्टवेयर के परीक्षण और विकास की लागत भी काफी हद तक कम हो जाती है।
अब बहुत देर नहीं हुई है! चलो आगे बढ़ो और तुरंत कीड़े तय हो जाओ!
.7z फ़ाइल क्या है
अनुशंसित पाठ
- क्यों बग रिपोर्टिंग एक कला है जिसे हर परीक्षक द्वारा सीखा जाना चाहिए?
- बिना किसी 'अमान्य बग' लेबल के अपने सभी बग्स को कैसे हल किया जाए?
- नमूना बग रिपोर्ट
- वेब और उत्पाद अनुप्रयोगों के लिए नमूना बग रिपोर्ट
- 3 सबसे खराब दोष रिपोर्टिंग की आदतें और उन्हें कैसे तोड़ना है
- 10 कारण क्यों आपके कीड़े अस्वीकार कर रहे हैं और आप एक परीक्षक के रूप में इसके लिए क्या कर सकते हैं!
- कैसे एक अच्छी बग रिपोर्ट लिखने के लिए? युक्तियाँ और चालें
- एप्लिकेशन में बग कैसे खोजें? युक्तियाँ और चालें