live project bug tracking
यह हमारे 'का समापन हिस्सा है लाइव प्रोजेक्ट पर सॉफ्टवेयर टेस्टिंग ट्रेनिंग ' श्रृंखला।
यह दोषों और कुछ शेष विषयों के बारे में होने जा रहा है जो एसटीएलसी के परीक्षण निष्पादन चरण के पूरा होने को चिह्नित करेगा।
में पिछला लेख , जबकि टेस्ट एक्ज़ेक्यूशन चल रहा था, हमें एक ऐसी स्थिति का सामना करना पड़ा जहाँ परीक्षण मामले का अपेक्षित परिणाम नहीं मिला। साथ ही, हमने खोजपूर्ण परीक्षण के दौरान कुछ अप्रत्याशित व्यवहार की पहचान की।
जब हम इन विचलन का सामना करते हैं तो क्या होता है?
हमें स्पष्ट रूप से उन्हें रिकॉर्ड करना होगा और यह सुनिश्चित करने के लिए उन्हें ट्रैक करना होगा कि ये विचलन संभाले और अंततः ऑटो पर तय हो।
# 1) इन विचलन को दोष / बग / मुद्दों / घटनाओं / त्रुटियों / दोष के रूप में जाना जाता है।
#दो) निम्नलिखित सभी मामलों को दोष के रूप में लॉग किया जा सकता है
- आवश्यकताओं की कमी
- गलत तरीके से काम करने की आवश्यकताएं
- अतिरिक्त आवश्यकताएं
- संदर्भ दस्तावेज़ विसंगतियां
- पर्यावरण से जुड़े मुद्दे
- एन्हांसमेंट सुझाव
# 3) दोष रिकॉर्डिंग ज्यादातर एक्सेल शीट में या दोष प्रबंधन सॉफ्टवेयर / उपकरण के उपयोग के माध्यम से की जाती है। उपकरणों के माध्यम से दोषों को कैसे संभालना है, इसकी जानकारी के लिए, निम्नलिखित लिंक का उपयोग करके देखें:
- एचपी एएलएम
- एटलसियन JIRA
- इसके अलावा, इस सूची के लिए इस पोस्ट का संदर्भ लें सबसे लोकप्रिय बग ट्रैकिंग उपकरण बाजार में।
आप क्या सीखेंगे:
- कैसे दोषों को प्रभावी ढंग से लॉग इन करें
- कुछ प्वाइंट्स जबकि बग ट्रैकिंग
- पूरा दोष जीवन चक्र
- ऑरेंजएचआरएम लाइव प्रोजेक्ट टेस्टिंग के लिए एक्जिट क्राइटेरिया
- परीक्षण मेट्रिक्स
- टेस्ट साइन ऑफ / कम्प्लीशन रिपोर्ट
- अनुशंसित पाठ
कैसे दोषों को प्रभावी ढंग से लॉग इन करें
अब हम यह देखने की कोशिश करेंगे कि एक्सेल शीट में पिछले लेख में हमारे द्वारा किए गए दोषों को कैसे लॉग किया जाए। हमेशा की तरह, एक मानक प्रारूप या टेम्पलेट चुनना महत्वपूर्ण है।
सर्वश्रेष्ठ वेबसाइटों ऑनलाइन मोबाइल फोनों के लिए देखने के लिए
आमतौर पर, निम्न स्तंभ दोष रिपोर्ट का एक हिस्सा होते हैं:
- दोष आईडी: विशिष्ट पहचान के लिए।
- दोष विवरण: यह मुद्दे का संक्षेप में वर्णन करने के लिए एक शीर्षक की तरह है।
- ऑटो का मॉड्यूल / अनुभाग: यह वैकल्पिक है, केवल ऑटो के क्षेत्र को इंगित करने के लिए और अधिक स्पष्टता जोड़ना जहां समस्या का सामना करना पड़ा था।
- प्रजनन के चरण: बग को फिर से बनाने के लिए ऑटो पर किए जाने वाले संचालन का सटीक क्रम यहां सूचीबद्ध होने के लिए क्या है। इसके अलावा, यदि कोई इनपुट डेटा उस समस्या के लिए विशिष्ट है, जिसमें जानकारी दर्ज की जानी है।
- तीव्रता: इस मुद्दे की तीव्रता और अंततः इसका असर ऑटो के कामकाज पर पड़ सकता है। कैसे असाइन किया जाए और इस क्षेत्र में क्या मान निर्दिष्ट किया जाए, इस दिशा-निर्देश को परीक्षण योजना दस्तावेज़ में पाया जा सकता है। तो, कृपया देखें आलेख 3 से परीक्षण योजना दस्तावेज़ ।
- स्थिति: लेख में आगे चर्चा की जाएगी।
- स्क्रीनशॉट: जब यह हुआ तब त्रुटि दिखाने के लिए एप्लिकेशन का एक स्नैपशॉट।
ये कुछ 'फ़ील्ड्स' होने चाहिए इस टेम्प्लेट का विस्तार किया जा सकता है (उदाहरण के लिए उस परीक्षक का नाम शामिल करना जिसने समस्या जारी की है) या अनुबंधित ( उदाहरण के लिए, आवश्यकतानुसार मॉड्यूल का नाम हटा दिया गया)।
उपरोक्त दिशानिर्देशों का पालन करना और ऊपर दिए गए टेम्पलेट का उपयोग करना, एक नमूना दोष लॉग / रिपोर्ट इस तरह दिख सकता है:
OrangeHRM लाइव परियोजना के लिए नमूना दोष रिपोर्ट:
=> लाइव परियोजना दोष रिपोर्ट डाउनलोड करने के लिए यहां क्लिक करें
नीचे नमूना दोष रिपोर्ट qTest परीक्षण प्रबंधन उपकरण में बनाई गई है: (बड़ा करने के लिए इमेज़ पर क्लिक करें)
दोष तब अच्छे नहीं होते जब हम उन्हें लॉग इन करते हैं और अपने पास रखते हैं। हमें संबंधित टीमों को उन पर कार्रवाई करने के लिए उन्हें सही क्रम में असाइन करना होगा। प्रक्रिया - किसे असाइन करना है या किस आदेश का पालन करना है यह भी टेस्ट प्लान डॉक्यूमेंट में पाया जा सकता है। यह ज्यादातर के समान है (बड़ा करने के लिए इमेज़ पर क्लिक करें)
दोष चक्र:
उपरोक्त प्रक्रिया से, यह ध्यान दिया जा सकता है कि कीड़े अलग-अलग लोगों के माध्यम से जाते हैं और निश्चित की पहचान की प्रक्रिया में विभिन्न निर्णय लेते हैं। ट्रैक करने के लिए और यह सुनिश्चित करने के लिए कि एक निश्चित बग किस स्थिति में है, बग रिपोर्ट में 'स्थिति' फ़ील्ड का उपयोग किया जाता है। पूरी प्रक्रिया को 'बग जीवन चक्र' के रूप में जाना जाता है। सभी स्थितियों और उनके अर्थों के बारे में अधिक जानकारी के लिए, कृपया इसे देखें बग जीवन चक्र ट्यूटोरियल ।
कुछ प्वाइंट्स जबकि बग ट्रैकिंग
- जब हम एक रचनात्मक टीम / प्रोजेक्ट / ऑटो के लिए नए होते हैं, तो यह हमेशा सबसे अच्छा होता है हमारे सामने आए मुद्दे पर चर्चा करें एक सहकर्मी के साथ यह सुनिश्चित करने के लिए कि दोष के लिए वास्तव में क्या बनाता है की हमारी समझ सही है या नहीं।
- सेवा सभी जानकारी प्रदान करें इस मुद्दे को पुन: पेश करने के लिए आवश्यक है। एक दोष जो एक परीक्षण टीम में वापस आता है, जिसे 'पर्याप्त जानकारी नहीं' के रूप में सेट किया गया है, यह हमारे ऊपर बहुत सकारात्मक रूप से प्रतिबिंबित नहीं होता है। इस पोस्ट को देखें - बिना किसी ’अमान्य बग’ लेबल के अपने सभी बगों को कैसे हल किया जाए ।
- जाँच करें कि क्या नया बनाने से पहले इसी तरह का मुद्दा उठाया गया था। 'डुप्लिकेट' समस्याएँ क्यूए टीम के लिए भी बुरी खबर है।
- यदि कोई समस्या है, तो वह बेतरतीब ढंग से सामने आती है और हम सटीक चरणों / स्थितियों को नहीं जानते हैं जिसमें हम इस मुद्दे को फिर से बना सकते हैं- इस मुद्दे को सभी एक ही उठा सकते हैं। इस मुद्दे के जोखिम पर सेट किया जा रहा है 'इररेप्रोडयूसीबल / पर्याप्त जानकारी नहीं' - हमें अभी भी यह सुनिश्चित करना है कि हम सभी संभव खराबी को यथासंभव सर्वोत्तम सीमा तक संभाले।
- सामान्य अभ्यास यह है कि क्यूए टीम एक दिन के दौरान एक्सेल शीट में प्रत्येक के दोषों का निर्माण करती है और इसे दिन के अंत में समेकित करती है।
पूरा दोष जीवन चक्र
हमारे लाइव प्रोजेक्ट के लिए अगर हम दोष 1 के लिए दोष जीवन चक्र का पालन करते थे,
कैसे एक eps फ़ाइल खोलने के लिए
- जब मैं (परीक्षक) इसे बनाता हूं, तो इसकी स्थिति है 'नवीन व”। जब मैं इसे क्यूए टीम लीड के लिए असाइन करता हूं, तो स्थिति अभी भी 'नई' है, लेकिन मालिक अब क्यूए लीड है।
- क्यूए लीड मुद्दे की समीक्षा करेगा और यह निर्धारित करने पर कि यह एक वैध मुद्दा है, इस मुद्दे को देव लीड को सौंपा गया है। इस चरण में, स्थिति है 'निरुपित' और मालिक देव लीड है।
- देव लीड तब इस मुद्दे को एक डेवलपर को सौंपेगा जो इस मुद्दे को ठीक करने पर काम करेगा। स्थिति अब होगी 'कार्य प्रगति पर है' (या उस प्रभाव के समान कुछ), मालिक डेवलपर है।
- दोष 1 के लिए, डेवलपर त्रुटि को पुन: पेश करने में सक्षम नहीं है, इसलिए वह इसे क्यूए टीम को वापस सौंप देता है और स्थिति निर्धारित करता है 'पुन: पेश करने में सक्षम नहीं”।
- वैकल्पिक रूप से, यदि डेवलपर इस पर काम करने और किसी समस्या को ठीक करने में सक्षम था, तो स्थिति निर्धारित की जाएगी 'संकल्प लिया' और मुद्दा QA टीम को वापस सौंपा जाएगा।
- QA की टीम तब इसे उठाएगी, इस मुद्दे को पुनःप्राप्त करेगी और यदि यह तय हो जाए, तो स्थिति निर्धारित कर देगी 'बंद किया हुआ' । यदि समस्या अभी भी मौजूद है, तो स्थिति सेट है 'फिर से खोलना' और प्रक्रिया जारी है।
- अन्य स्थितियों के आधार पर, स्थिति निर्धारित की जा सकती है 'स्थगित' , 'ज्यादा जानकारी नहीं है', 'डुप्लिकेट' , 'इरादा के अनुसार काम करना' , डेवलपर द्वारा आदि।
- दोषों की रिकॉर्डिंग, रिपोर्टिंग और उन्हें असाइन करने, उन्हें प्रबंधित करने का यह तरीका परीक्षण निष्पादन चरण के दौरान क्यूए टीम के सदस्यों द्वारा की गई प्रमुख गतिविधियों में से एक है। यह एक विशेष परीक्षण चक्र पूरा होने तक दैनिक आधार पर किया जाता है।
- एक बार जब चक्र 1 हो जाता है, तो देव टीम को एक या दो दिन लगेंगे ताकि सभी सुधारों को समेकित किया जा सके और अगले चक्र में कोड का पुनर्निर्माण किया जा सके।
- यही प्रक्रिया फिर से चक्र 2 के लिए भी जारी है। चक्र के अंत में, एक मौका है कि अभी भी कुछ मुद्दे 'ओपन' हो सकते हैं या एप्लिकेशन में अप्रकाशित हो सकते हैं।
- इस स्तर पर- क्या हम अभी भी साइकिल 3 के साथ जारी हैं? यदि हाँ, तो हम परीक्षण कब रोकेंगे?
ऑरेंजएचआरएम लाइव प्रोजेक्ट टेस्टिंग के लिए एक्जिट क्राइटेरिया
यह वह जगह है जहां हम रोजगार करते हैं जिसे हम 'एक्जिट क्राइटेरिया' कहेंगे। यह टेस्ट प्लान दस्तावेज में पूर्व-परिभाषित है। यह बस चेकलिस्ट के रूप में है जो यह निर्धारित करेगा कि हम चक्र 2 के बाद परीक्षण समाप्त करते हैं या एक और चक्र के लिए जाते हैं। यह ऐसा दिखता है, नीचे दिया गया है जब ऑरेंजएचआरएम परियोजना से संबंधित निम्नलिखित सवालों के कुछ काल्पनिक जवाबों को ध्यान में रखते हुए:
जब हम उपरोक्त चेकलिस्ट को ध्यान से देखते हैं, तो वहां मेट्रिक्स और साइन ऑफ होते हैं जिनका उल्लेख हमने पहले नहीं किया है। अब हम उनके बारे में बात करते हैं।
परीक्षण मेट्रिक्स
हमने स्थापित किया है कि परीक्षण निष्पादन चरण के दौरान, रिपोर्ट के बारे में स्पष्ट जानकारी देने के लिए अन्य सभी परियोजना टीम के सदस्यों को रिपोर्ट भेजी जाती है क्यूए निष्पादन चरण में क्या हो रहा है । अंतिम उत्पाद की समग्र गुणवत्ता के बारे में मान्यता प्राप्त करने के लिए यह जानकारी सभी के लिए महत्वपूर्ण है।
कल्पना कीजिए कि मैं रिपोर्ट करता हूं कि 10 परीक्षण मामले पारित हुए या 100 परीक्षण मामलों को निष्पादित किया गया- ये संख्या केवल कच्चे डेटा हैं और इस बारे में बहुत अच्छा परिप्रेक्ष्य नहीं देते हैं कि चीजें कैसे चल रही हैं।
मेट्रिक्स इस अंतर को भरने में महत्वपूर्ण भूमिका निभाते हैं। मेट्रिक्स सरल शब्दों में हैं, बुद्धिमान संख्याएं जिन्हें परीक्षण टीम एकत्र करती है और बनाए रखती है । उदाहरण के लिए, अगर मैंने कहा कि 90% टेस्ट केस पास हुए हैं, तो 150 टेस्ट केस पास होने की तुलना में यह ज्यादा मायने रखता है। क्या यह नहीं है?
परीक्षण निष्पादन चरण के दौरान विभिन्न प्रकार के मेट्रिक्स एकत्र किए जाते हैं। मेट्रिक्स वास्तव में क्या समय के लिए एकत्र और बनाए रखा जाना चाहिए- यह जानकारी परीक्षण योजना दस्तावेज़ में पाई जा सकती है।
अधिकांश परियोजनाओं के लिए सबसे अधिक एकत्र किए जाने वाले परीक्षण मीट्रिक निम्नलिखित हैं:
- टेस्ट मामलों का प्रतिशत पास
- घनत्व को कम करता है
- महत्वपूर्ण दोष प्रतिशत
- दोष, गंभीरता वार संख्या
इसकी जाँच पड़ताल करो इस लेख से जुड़ी स्थिति रिपोर्ट यह देखने के लिए कि इन मीट्रिक का उपयोग कैसे किया जाता है।
टेस्ट साइन ऑफ / कम्प्लीशन रिपोर्ट
जैसा कि हमें सभी हितधारकों को सूचित करना है कि परीक्षण शुरू हो गया है, यह भी क्यूए टीम का कर्तव्य है कि सभी को बताएं कि परीक्षण पूरा हो गया है और परिणाम साझा करें। इसलिए, आम तौर पर क्यूए टीम (आमतौर पर टीम लीड / क्यूए मैनेजर) से एक ईमेल भेजा जाता है जो यह संकेत देता है कि क्यूए टीम ने परीक्षण के परिणाम और खुले / ज्ञात मुद्दों की सूची संलग्न करने वाले उत्पाद पर हस्ताक्षर किए हैं।
नमूना परीक्षण ईमेल से साइन इन करें:
सेवा: ग्राहक, पीएम, देव टीम, डीबी टीम, बीए, क्यूए टीम, पर्यावरण टीम (और किसी को भी शामिल करने की आवश्यकता है)
ईमेल: हैलो टीम,
वेबसाइट के कार्यात्मक परीक्षण के 2 चक्रों के सफल समापन के बाद, ऑरेंजएचआरएम संस्करण 3.0 सॉफ्टवेयर पर क्यूए टीम साइन ऑफ करती है।
परीक्षण के मामले और उनके निष्पादन के परिणाम ईमेल से जुड़े होते हैं। (या उस स्थान का उल्लेख करें जहां वे मौजूद हैं। या यदि परीक्षण प्रबंधन सॉफ़्टवेयर का उपयोग कर रहे हैं, तो उसी के बारे में विवरण प्रदान करें।)
ज्ञात मुद्दों की सूची ईमेल से भी जुड़ी हुई है। (फिर, कोई अन्य संदर्भ जो समझ में आता है उसे जोड़ा जा सकता है।)
धन्यवाद,
क्यूए टीम लीड।
अनुलग्नक: अंतिम निष्पादन रिपोर्ट, अंतिम मुद्दा / दोष रिपोर्ट, ज्ञात समस्या सूची
एक बार टेस्ट साइन ऑफ ईमेल QA टीम से निकल जाने के बाद, हम आधिकारिक तौर पर STLC प्रक्रिया के साथ हो जाते हैं। यह एसडीएलसी के 'टेस्ट' चरण को पूरा करने के लिए जरूरी नहीं है। हमारे पास अभी भी यूएटी परीक्षण है जो कि होने के लिए समाप्त होगा। का पता लगाएं UAT परीक्षण के बारे में अधिक जानकारी यहाँ ।
UAT हो जाने के बाद, SDLC उस चरण में परिनियोजित करने के लिए जाता है जहां वह लाइव होता है और अपने ग्राहकों / अंतिम उपयोगकर्ताओं के लिए उपलब्ध होता है।
इतना ही!
यह हमारे पाठकों के लिए क्यूए प्रोजेक्ट अनुभव की तरह सबसे अधिक लाइव लाने का हमारा प्रयास रहा है। कृपया हमें इस मुफ्त ऑनलाइन सॉफ्टवेयर परीक्षण क्यूए प्रशिक्षण श्रृंखला के बारे में अपनी टिप्पणी और प्रश्न बताएं।
अनुशंसित पाठ
- सॉफ्टवेयर टेस्टिंग ट्रेनिंग: एक लाइव प्रोजेक्ट पर एंड टू एंड ट्रेनिंग - फ्री ऑनलाइन क्यूए ट्रेनिंग पार्ट 1
- एसआरएस दस्तावेज़ से टेस्ट केस लिखना (लाइव प्रोजेक्ट सैंपल टेस्ट मामले को डाउनलोड करें)
- सॉफ्टवेयर टेस्टिंग QA ट्रेनिंग कोर्स FAQs
- 2021 में परेशानी-मुक्त प्रशिक्षण के लिए 11 सर्वश्रेष्ठ ऑनलाइन प्रशिक्षण सॉफ्टवेयर
- कीवर्ड दृश्य के साथ कार्य करना - QTP प्रशिक्षण ट्यूटोरियल 2
- सॉफ्टवेयर परीक्षण में दोष / बग जीवन चक्र क्या है? दोषपूर्ण जीवन चक्र ट्यूटोरियल
- JIRA बग ट्रैकिंग टूल ट्यूटोरियल: JIRA का उपयोग टिकटिंग टूल के रूप में कैसे करें
- एसआरएस दस्तावेज़ की समीक्षा कैसे करें और टेस्ट परिदृश्य बनाएं - लाइव प्रोजेक्ट पर सॉफ्टवेयर परीक्षण प्रशिक्षण - दिन 2