3 strategies dealing with blocker defect
अवरोधक दोष, अन्यथा नियमित रूप से परीक्षण के दिनों में बहुत सारे नाटक जोड़ते हैं।
इस लेख में, मैं कुछ चरणों को कवर करना चाहता हूं जो एक परीक्षक उनसे निपटने के दौरान ले सकता है।
मैं यह मानने जा रहा हूं कि हमारे प्रिय पाठक पहले से ही गंभीरता और दोषों की प्राथमिकता को गहराई से समझते हैं। एक त्वरित पुनरावृत्ति की आवश्यकता है? इसकी जांच करें।
अब, क्या इसका मतलब यह है कि यदि हम एक अवरोधक मुद्दे पर आते हैं तो हमें परीक्षण पूरी तरह से बंद करने की आवश्यकता है?
कुछ मामलों में 'हाँ', लेकिन शायद हमेशा नहीं। ऐसे उदाहरण हो सकते हैं जहां कुछ परीक्षण गतिविधि संभव है।
छवि स्रोत
नीचे कुछ परिस्थितियाँ हैं जो मैंने अपने करियर में एक परीक्षक के रूप में अनुभव की हैं। मेरा दृढ़ता से मानना है कि इस प्रक्रिया को सरल बनाने के लिए नीचे दिए गए चरणों (बाद में एक फ्लोचार्ट में समेकित) का पालन किया जाना है।
चलो सही में कूदो
जब आप एक अवरोधक दोष में आते हैं तो आपको कदम उठाने चाहिए
चरण 1: जब आप किसी मुद्दे पर आते हैं, तो मूल कारण खोजने के लिए समय का निवेश करें।
मेरा दृढ़ता से मानना है कि एक परीक्षक के रूप में हमारा काम अभी समाप्त नहीं हुआ है रिपोर्टिंग दोष । यदि समय अनुमति देता है, तो हमें यह पता लगाना चाहिए कि समस्या का कारण क्या हो सकता है। हम हमेशा सटीक समस्या क्षेत्र को इंगित करने में सक्षम नहीं हो सकते हैं, लेकिन जितना संभव हो उतना समस्या निवारण करने का प्रयास करें। अतिरिक्त विवरण के रूप में एक ही विवरण को दोष में अद्यतन किया जा सकता है।
मैंने अपनी परियोजनाओं में बहुत कुछ किया है, और इसके परिणामस्वरूप त्वरित सुधार हुआ है। मूल कारण विश्लेषण के लाभ हैं:
- वैल्यू-ऐड होने के नाते, यह निश्चित रूप से बग फिक्सिंग के लिए डेवलपर को बेहतर दिशा प्रदान कर सकता है।
- इसके अलावा, क्यूए परीक्षक यह पहचान सकता है कि क्या यह मुद्दा स्व-निर्मित (डेटा प्रविष्टि या मानव उपयोग की समस्याएं) है और यदि ऐसा है, तो परीक्षक द्वारा ही तय किया जा सकता है। जब इस तरह की त्रुटियां डेवलपर्स को रिपोर्ट की जाती हैं, तो हमारे बिना क्यूए के अंत से जाँच कर रहे हैं, वे हैं एक गैर-मुद्दा माना जाता है और परीक्षक के लिए एक नकारात्मक प्रतिष्ठा बना सकता है।
इसलिए, मेरा सुझाव है कि हम एक दोष को लॉग करने से पहले हमेशा हमारे अंत में दोहरी जांच करें।
यहाँ मेरी परियोजनाओं से कुछ वास्तविक समय के उदाहरण हैं जो उपरोक्त बिंदुओं को सुदृढ़ करेंगे:
मैंने एक ऐसी परियोजना पर काम किया, जहाँ हमारे परीक्षण के लिए हमें एक निर्दिष्ट स्थान पर एक फ़ाइल छोड़नी होगी। कॉन्फ़िगरेशन में नाम से मेल करने के लिए इसका नाम बदलें। एक शेड्यूल किया गया कार्य डेटा फ़ाइल को उठाएगा और डेटा को सिस्टम में लोड करेगा। जिसके बाद, हम डेटाबेस और सामने के छोर में डेटा को मान्य करेंगे।
मूल्यांकन के नमूने में पदोन्नति के लिए पूछ रहा है
हम उन मुद्दों पर आते थे जहां नौकरी चलेगी लेकिन डेटा लोड नहीं होगा, और जांच करने पर, ऐसा इसलिए था क्योंकि परीक्षक ने स्थान पर फ़ाइल को गिराते समय नाम नहीं बदला है।
यह हमारे लिए एक अवरोधक था, लेकिन ऐसा कुछ नहीं था जिसके लिए डेवलपर का ध्यान आवश्यक हो। हमें इस तरह की छोटी गलतियों पर विस्तार और ध्यान देने की जरूरत है।
निम्नलिखित कुछ सामान्य श्रेणियां हैं, मूल कारण और उपाय:
(1) होस्ट फ़ाइल समस्या - कहो, आपकी मेजबानों फ़ाइल में पैरामीटर हैं जो गलत हैं और समस्या का कारण बन रहे हैं। इस स्थिति में, आप या तो होस्ट फ़ाइल को स्वयं अपडेट कर सकते हैं या अपडेट के लिए किसी से सहायता ले सकते हैं और परीक्षण निष्पादन जारी रख सकते हैं।
उसी के लिए एक दोष उठाया जाना चाहिए ताकि डेवलपर्स जांच करेंगे लेकिन वर्कअराउंड के साथ कार्यात्मक परीक्षण अभी भी जारी रखा जा सकता है।
ध्यान दें: ऐसा करने से पहले इन परिवर्तनों को करने के लिए QA टीम के लिए ठीक है, तो अपनी प्रोजेक्ट टीमों के साथ जांचें।
# 2) विन्यास - अक्सर, हमने कॉन्फ़िगरेशन समस्याओं को नोट किया है जैसे कि सही वातावरण या अन्य सेट अप समस्याओं की ओर इशारा नहीं करते हैं, जो समस्याओं को रोक रहे हैं। ऐसे मामलों में भी, परीक्षक परिवर्तन कर सकते हैं और परीक्षण के साथ आगे बढ़ सकते हैं।
ध्यान दें: एक बार फिर, ऐसा करने से पहले अनुमति लें।
# 3) कोड जारी - यदि आपको लगता है कि समस्या कोड के कारण है, तो परीक्षकों द्वारा कुछ भी नहीं किया जा सकता है। एक अवरोधक दोष लॉग करें और परीक्षण के लिए आगे बढ़ने के लिए प्रतीक्षा करें।
# 4) तैनाती मुद्दा - खराब तैनाती अवरोधक मुद्दों का एक और सामान्य कारण है और इन्हें पवित्रता परीक्षण के दौरान पकड़ा जा सकता है। यहां भी, एक नया निर्माण प्राप्त होने तक परीक्षण को तुरंत रोक दिया जाना चाहिए।
# 5) पर्यावरण नीचे - यदि पर्यावरण नीचे है, तो कहें कि डेटाबेस सर्वर से कनेक्ट नहीं हो रहा है या वेबसाइटों के मामले में URL काम नहीं कर रहा है; परीक्षक इन मामलों में एक दोष की रिपोर्ट करने के अलावा बहुत कुछ नहीं कर सकते हैं और सिस्टम के उठने और चलने की प्रतीक्षा कर सकते हैं।
इसलिए, यदि कोई वर्कअराउंड मौजूद है, तो परीक्षण जारी रखने के लिए इसका उपयोग करें। खोजने का एकमात्र तरीका, अगर यह कहा गया है कि वर्कअराउंड मौजूद है, मूल कारण की जांच करके है। अधिक बार नहीं, एक विकल्प हो सकता है।
चरण 2: मूल कारण की जांच करते समय एक अनंत लूप में गिरना बहुत आसान है। इसलिए, सुनिश्चित करें कि यह पूरे दिन और सभी प्रयासों का उपभोग नहीं कर रहा है।
यहाँ कुछ संकेत दिए गए हैं:
- संतुलन प्राप्त करें और जब आप वहां पहुंचें तो रोक बिंदु को पहचानें।
- एक सफल RCA के लिए एक परीक्षक का अनुभव और विशेषज्ञता महत्वपूर्ण है। हालांकि, जब आवश्यक हो, टीम और टीम लीड को शामिल करना एक अच्छा विचार है।
- जब आपको लगता है कि आरसीए समय लेने वाली है, तो पहले इस मुद्दे की तुरंत रिपोर्ट करें और जितनी जानकारी हो सके प्रदान करें। एक स्क्रीनशॉट हमेशा मददगार होता है।
- यदि आवश्यक हो, का पालन करें। महत्वपूर्ण समस्या की ओर ध्यान दिलाने के लिए प्रबंधक या डेवलपर को एक ईमेल भेजें।
- आवश्यक पक्षों को अलर्ट करने के बाद समस्या निवारण जारी रखें।
क्यों ब्लॉकर दोषों की सूचना तुरंत दी जानी चाहिए:
- यदि समस्या शोस्टॉपर दोष की होती है तो प्रबंधन को सभी डाउनटाइम्स से अवगत कराया जाना चाहिए। इस जानकारी को क्लाइंट के पास भेजना होगा और प्रोजेक्ट प्लान अपडेट (क्यूए टाइमलाइन), डिलिवरी में बदलाव आदि के लिए भी कॉल कर सकते हैं।
- क्यूए डिलिवरेबल्स में किसी भी देरी को सबूत के साथ समर्थन करना होगा। इसलिए दिन के अंत तक इंतजार करने के बजाय जितनी जल्दी हो सके संवाद करना हमेशा बेहतर होता है।
चरण 3: अब, हम इस मुद्दे का विश्लेषण करने और इसे संप्रेषित करने के लिए अंतिम चरण पर चल रहे हैं, आगे क्या है?
- यदि समस्या एक कार्यात्मक क्षेत्र तक पहुंच को रोक रही है, तो जांचें कि क्या इसका अन्य क्षेत्रों पर प्रभाव है
- यदि फ्रंट एंड ऐप डाउन है, तो बैकेंड / मिडलवेयर / डेटाबेस टेस्टिंग को जारी रखा जा सकता है।
- यदि कोई परीक्षण निष्पादन गतिविधि नहीं हो सकती है, तो प्रयास करें कुछ प्रलेखन पर काम करते हैं अपने प्रोजेक्ट से संबंधित।
- आप भी आजमा सकते हैं स्वचालन के लिए क्षेत्रों की पहचान करें यदि आप मैन्युअल रूप से बहुत काम दोहरा रहे हैं। स्वचालन को हमेशा एक उपकरण का उपयोग नहीं करना पड़ता है कहते हैं, रिपोर्ट जनरेशन आपके लिए एक नीरस काम है, यह एक ऐसा क्षेत्र है जिसे सरल एक्सेल मैक्रोज़ और इस तरह से स्वचालित किया जा सकता है।
- ओपन सोर्स टूल्स के बारे में जानने में समय व्यतीत करें जो आपके प्रोजेक्ट में लागू हो सकते हैं
- अंतिम लेकिन कम नहीं , नवाचार की दिशा में, वर्तमान में दुनिया पर राज करने वाला मंत्र!
आखिरकार संपूर्ण चर्चा का सारांश प्रस्तुत करने वाला फ्लोचार्ट!
सॉफ्टवेयर कंप्यूटर में डीवीडी कॉपी करने के लिए
फ़्लोचार्ट: एक अवरोधक दोष को संभालने के लिए कदम
लेखक : यह भयानक लेख एसटीएच टीम की सदस्य प्रिया आर द्वारा लिखा गया है।
किसी भी अवरोधक दोष के सामने आने पर आप क्या कदम उठाते हैं?
अनुशंसित पाठ
- दोष आधारित परीक्षण तकनीक क्या है?
- सॉफ्टवेयर परीक्षण में दोष / बग जीवन चक्र क्या है? दोषपूर्ण जीवन चक्र ट्यूटोरियल
- दोष प्रबंधन प्रक्रिया: प्रभावी रूप से एक दोष प्रबंधन कैसे करें
- सर्वश्रेष्ठ सॉफ्टवेयर परीक्षण उपकरण 2021 (क्यूए टेस्ट स्वचालन उपकरण)
- वेब और उत्पाद अनुप्रयोगों के लिए नमूना बग रिपोर्ट
- कैसे एक गैर- Reproducible दोष को पुन: उत्पन्न करने के लिए और अपने परीक्षण प्रयास इसे बनाने के लिए
- सॉफ्टवेयर परीक्षण विचारों के बारे में है (और उन्हें कैसे उत्पन्न करें)
- सॉफ्टवेयर परीक्षण के 7 सिद्धांत: दोष क्लस्टरिंग और पेरेटो सिद्धांत