how do you decide which defects are acceptable
सॉफ्टवेयर गो-लाइव हमेशा किसी भी सॉफ्टवेयर उत्पाद के लिए एक बड़ी घटना है। यह सुनिश्चित करना महत्वपूर्ण है कि सब कुछ काम करता है और हम हैं उपयोगकर्ताओं को गुणवत्ता सॉफ्टवेयर जारी करना ।
खराब या समय से पहले या अस्थिर या उत्पाद का उपयोग करने में मुश्किल से वित्तीय रूप से बहुत अधिक नुकसान हो सकता है और उपयोगकर्ता को ब्रांड में खुद पर विश्वास भी खो सकता है।
अक्सर बार, हम सुनते हैं कि परीक्षण तब तक किया जाना चाहिए जब तक हम बाहर निकलने के मानदंडों को पूरा नहीं करते। हम यह भी सुनते हैं कि दोषों को एक स्वीकार्य स्तर पर तय किया जाना है।
हालांकि, ये बहुत अच्छे लगने वाले दिशा-निर्देश हैं, ये अस्पष्ट हैं।
अधिक विशिष्ट होना:
- सॉफ़्टवेयर को लाइव करने के लिए कितने प्रतिशत दोष स्वीकार्य हैं?
- आप खुले दोषों पर कैसे निर्णय लेते हैं कि सॉफ्टवेयर के साथ रह सकते हैं?
- क्या दोष के प्रकार दूसरों की तुलना में अधिक गंभीर हैं?
अनुशंसित पढ़ने => परीक्षण कब रोकना है?
क्या आपने कभी ये सवाल किए हैं? फिर, यह लेख आपको उनका उत्तर देने में मदद करने वाला है। पढ़ते रहिये…
कॉम्प्लेक्स सॉफ्टवेयर मुक्त दोष नहीं है और यह एक चिकन और अंडे की कहानी है जो दोष-ए-विज़ काम कर रहे सॉफ़्टवेयर को बंद कर देता है।
जितना अधिक आप दोषों को ठीक करते हैं, अधिक संभावना है कि दोष को बंद करते समय एक नया दोष इंजेक्ट किया गया है। इसलिए,
- आप दोषों की सीमा और उन दोषों के प्रकार पर कैसे निर्णय लेते हैं जिनके साथ आप जा सकते हैं?
- आप गो-लाइव के लिए तैनात किए जाने वाले सॉफ़्टवेयर को कैसे आधारभूत करते हैं?
- यूएटी समन्वयक गो-लाइव को कॉल कैसे करते हैं या नहीं?
- सॉफ्टवेयर को किन मानकों के खिलाफ जाना चाहिए?
- हम कैसे उत्तर देते हैं - क्या सॉफ्टवेयर उपयोग के लिए उपयुक्त है और क्या यह हितधारकों के लिए मूल्य लाएगा?
उत्पादन में लाइव जाना ग्राहक के लिए एक प्रमुख मील का पत्थर है और साथ ही विक्रेता के रूप में यह आमतौर पर भुगतान मील के पत्थर से जुड़ा हुआ है। यह सुनिश्चित करने में दोनों की समान जिम्मेदारी है कि बड़ी परिवर्तनकारी परियोजनाएं सफल हैं।
मेरा अनुभव बताता है कि ग्राहक पैसे के लिए अपना मूल्य चाहते हैं और ए बाहर निकलने की कसौटी यूएटी के साथ रहने के लिए।
उक्त निकास मापदण्ड कमोबेश सभी क्षेत्रों में समस्याओं की स्वीकार्य सीमा को परिभाषित करेगा, जैसे:
- कार्यात्मक
- प्रदर्शन और लोड
- प्रयोज्य
- सुरक्षा
- बाहरी प्रणालियों के साथ एकीकरण
- रिपोर्टों
- आंकड़ों का विस्थापन
मेरा मानना है कि इन प्रकारों में से हर एक को आगे समझाया जाना चाहिए। और, ठीक यही अब हम करेंगे:
.net साक्षात्कार और अनुभवी के लिए जवाब
# 1 कार्यात्मक दोष:
यदि सॉफ़्टवेयर ग्राहक द्वारा दिए गए विनिर्देशों के अनुसार बनाया गया है, तो उसे आवश्यकताओं को पूरा करना होगा। किसी भी विचलन को कार्यात्मक दोष के रूप में लॉग किया जाता है।
क्रियात्मक दोष तब के अनुसार वर्गीकृत किया जाता है गंभीरता और प्राथमिकता ।
निम्नलिखित महत्वपूर्ण विचार हैं:
- उच्च गंभीरता और प्राथमिकता दोष आमतौर पर ऐसे होते हैं जो सॉफ्टवेयर के दैनिक उपयोग को प्रभावित करते हैं। इस प्रकार के दोष वे हैं जो हमें जाने से पहले निश्चित होने चाहिए। कोई अपवाद नहीं।
- कभी-कभी कार्यात्मक दोषों को परिवर्तन अनुरोधों के रूप में वर्गीकृत किया जाता है क्योंकि वे मूल रूप से दी गई आवश्यकताओं का हिस्सा नहीं थे। इस तरह के सीआर, जो गो-लाइव के बाद व्यापार के लिए आवश्यक हैं, को भी लागू किया जाना चाहिए।
- व्यावसायिक उपयोगकर्ताओं और व्यावसायिक विश्लेषकों के सहयोग से यूएटी समन्वयकों द्वारा दोषों का वर्गीकरण और कार्यात्मक दोषों का प्राथमिकताकरण किया जाता है। आमतौर पर, ग्राहक के पास यह मानदंड होता है कि गो-लाइव के लिए कितने% दोष खुले हो सकते हैं।
# २। प्रदर्शन और लोड दोष:
प्रदर्शन दोष गो-लाइव के लिए विचार करना महत्वपूर्ण है और इसलिए यदि बाहरी उपयोगकर्ताओं द्वारा सॉफ़्टवेयर का उपयोग किया जाना है।
यदि किसी दी गई संख्या के लिए सॉफ़्टवेयर धीमा है, तो उपयोगकर्ता सॉफ़्टवेयर का उपयोग करने से बचेंगे क्योंकि इसे लोड होने में बहुत समय लगता है। यदि सॉफ्टवेयर बहुत धीमा हो जाता है, तो उपयोगकर्ता प्रतिस्पर्धात्मक स्थल की ओर रुख करते हैं जिससे व्यापार में कमी आती है
कभी-कभी, एप्लिकेशन के कुछ हिस्से जो क्लाइंट का सामना नहीं कर रहे हैं, वे भी प्रदर्शन को प्रभावित कर सकते हैं।
उदाहरण के लिए: यदि कोई बैच प्रक्रिया है जो हर दिन के अंत में चलती है और यदि आवेदन की प्रतिक्रिया समय बीतने पर होती है, तो बैच का प्रदर्शन भी विचार करने का एक कारक है।
- प्रदर्शन को आमतौर पर स्क्रीन के प्रतिक्रिया समय के संदर्भ में मापा जाता है ताकि उपयोगकर्ताओं को रेंडर किया जा सके और उपलब्ध हो सके, जबकि सिस्टम पर एक निश्चित संख्या में समवर्ती उपयोगकर्ता होते हैं।
- प्रदर्शन परीक्षण जैसे उपकरणों का उपयोग करके किया जाता है लोडरनर , WebLoad , नियोलोद आदि।
- किसी दिए गए लोड पर और भविष्य में अनुमानित लोड पर सॉफ़्टवेयर का प्रदर्शन आमतौर पर अनुबंध में दर्ज़ किया जाता है और इसे गो-लाइव से पहले प्रदर्शित किया जाता है।
- उपयोगकर्ताओं द्वारा कम उपयोग किए जाने वाले एप्लिकेशन या स्क्रीन के कुछ हिस्सों को गो-लाइव के बाद मूल्यांकन के लिए स्थगित कर दिया जाता है।
- प्रदर्शन हार्डवेयर और नेटवर्क स्थितियों के प्रकार पर भी निर्भर करता है, जिस पर सॉफ्टवेयर को तैनात किया जाता है।
- प्रदर्शन परीक्षण यूएटी के दौरान प्रदर्शन उपकरणों का उपयोग करके निर्दिष्ट हार्डवेयर में किया जाता है और उनके दोषों को कार्यात्मक दोषों के समान फैशन में ट्रैक किया जाता है। उन्हें प्राथमिकता भी दी जाती है और गो-लाइव के लिए निकास मानदंडों को पूरा करने पर एक आम सहमति बन जाती है।
- आमतौर पर यूएटी में प्रदर्शन और लोड परीक्षण कार्यात्मक यूएटी के बाद होता है, जो व्यापार उपयोगकर्ताओं द्वारा पूरा किया जाता है और कार्यात्मक दोषों के लिए स्वीकार्य निकास मानदंड पर पहुंच जाता है।
# ३। प्रयोज्यता दोष:
सॉफ्टवेयर बनाया अंत उपयोगकर्ताओं द्वारा आसानी से उपयोग करने योग्य होना चाहिए विभिन्न हॉटकी, शॉर्टकट, स्क्रीन नेविगेशन, पेजिनेशन आदि की न्यूनतम संख्या का उपयोग करना। सॉफ्टवेयर को स्मार्ट और सहज होना चाहिए।
यदि उपयुक्त स्क्रीन पर जाने से पहले पृष्ठ के बहुत सारे मूवमेंट हैं, तो उपयोगकर्ता आमतौर पर सॉफ़्टवेयर का उपयोग करने में कम रुचि दिखाते हैं।
- सॉफ्टवेयर के निर्माण से पहले प्रयोज्य दिशानिर्देश बनाए जाते हैं। सॉफ्टवेयर को इन दिशानिर्देशों का पालन करना होगा।
- सॉफ़्टवेयर बनाते समय उपकरण प्रतिबंध भी हो सकते हैं, जो अंतिम उपयोगकर्ताओं द्वारा उपयोग करने योग्य सॉफ़्टवेयर से पहले स्मार्ट तरीके से पार करना पड़ता है।
- अत्यधिक उपयोग करने योग्य सॉफ्टवेयर के साथ, एक अंतिम उपयोगकर्ता नियमित सॉफ्टवेयर से 5 गुना अधिक डेटा इनपुट कर सकता है।
- सॉफ्टवेयर के लुक और फील को कुरकुरा होना चाहिए और गो-लाइव से पहले कानूनी मुद्दों को भी सुलझाना होगा।
- कई बार उपयोगकर्ताओं के लिए सहज प्रयोज्य अनुभव सुनिश्चित करने के लिए एक प्रयोज्य सलाहकार नियुक्त किया जाता है।
- सॉफ़्टवेयर अनुप्रयोग के साथ बाहर जाने के लिए प्रलेखन को भी कड़े प्रयोज्य दिशानिर्देशों का पालन करना पड़ता है क्योंकि वे कानूनी रूप से उपयोग किए जा सकते हैं।
- यूएटी परीक्षकों / बाहरी परीक्षकों द्वारा उपयोग किए जाने वाले प्रयोज्य दोषों को कार्यात्मक और प्रदर्शन दोषों के रूप में भी प्राथमिकता दी जाती है और उन्हें गो-लाइव के लिए निकास मानदंडों को पूरा करना पड़ता है।
# ४। सुरक्षा दोष:
सुरक्षा सॉफ्टवेयर एक हॉट इशू है क्योंकि सॉफ्टवेयर एप्लीकेशन को हैक किया जा सकता है और ग्राहक के संवेदनशील डेटा को कुछ ही समय में चुराया जा सकता है।
इसलिए, विश्वसनीय सॉफ्टवेयर को उचित विशेषाधिकार के बिना आवेदन में बहुत सक्षम हैकर को भी अनुमति नहीं देनी चाहिए।
- यूएटी में सुरक्षा परीक्षण सॉफ्टवेयर में विशिष्ट इनपुट के साथ किया जाता है ताकि यह सुनिश्चित किया जा सके कि यह हैक करने योग्य नहीं है।
- सुरक्षा परीक्षण कानूनी हैकरों द्वारा किया जाता है जो यह जांचने के लिए सॉफ़्टवेयर को हैक करने की कोशिश करते हैं कि क्या यह असुरक्षित है।
- सिस्टम के लाइव होने से पहले सभी सुरक्षा दोषों को बंद करना होगा।
- सुरक्षा का अर्थ है कि विभिन्न उपयोगकर्ताओं (बाहरी और आंतरिक) के लिए लॉगिन और भूमिकाएं और विशेषाधिकार एप्लिकेशन के विभिन्न वर्गों का उपयोग करें और डेटा बनाने और अनुमोदन के लिए भी।
# 5 बाहरी सॉफ्टवेयर सिस्टम के साथ एकीकरण:
आमतौर पर, एक सॉफ़्टवेयर एप्लिकेशन जिसे ग्राहक की साइट पर तैनात किया जाना है, उसे किसी भी मौजूदा सॉफ़्टवेयर के साथ इंटरफ़ेस करना होगा जो पहले से ही वहां मौजूद हो सकता है।
उदाहरण के लिए: मुद्रण प्रणाली के साथ, उनका उपयोग होता है या यह बाहरी सिस्टम हो सकता है जैसे बिलिंग एप्लिकेशन या डेटा स्क्रीन सिस्टम। तैनात किए जा रहे सॉफ़्टवेयर एप्लिकेशन को मूल रूप से इन बाहरी प्रणालियों के साथ एकीकृत किया जाना चाहिए। इन प्रणालियों के लिए सभी इनपुट और आउटपुट तुल्यकालिक रूप से काम करना चाहिए। प्रौद्योगिकी आज मोबाइल एप्लिकेशन और विभिन्न सॉफ्टवेयर प्लेटफ़ॉर्म को शामिल करती है जो एप्लिकेशन को होना चाहिए के साथ संगत ।
सिस्टम और यूएटी चरणों के दौरान बाहरी सिस्टम इंटरफेसिंग की जाँच बड़े पैमाने पर की जानी चाहिए। यह बाहर निकलने के मानदंडों पर होना चाहिए जो कि गो-लाइव से पहले संतुष्ट होना चाहिए।
# 6 रिपोर्ट:
सॉफ़्टवेयर एप्लिकेशन की रिपोर्ट यह दिखाने का एक महत्वपूर्ण तरीका है कि एप्लिकेशन के अंदर का डेटा टैली कर रहा है।
उदाहरण के लिए: सभी बिलिंग से संबंधित डेटा को क्रेडिट और डेबिट शेष में जमा करना होगा।
- सॉफ्टवेयर के सभी डेटा को समेटना होगा। सॉफ्टवेयर के भीतर डेटा के इस सामंजस्य को रिपोर्टों के माध्यम से दिखाया गया है और उन्हें काम करना चाहिए।
- यह विशेष रूप से सच है यदि एक पुरानी प्रणाली से एक नई प्रणाली में डेटा स्थानांतरण वर्तमान रिलीज का प्राथमिक उद्देश्य है।
# 7 आंकड़ों का विस्थापन:
यदि एक पुरानी प्रणाली को एक नए से बदला जा रहा है, तो पुरानी प्रणाली से डेटा को नए में ले जाया जाता है (नई प्रणाली का उपयोग करके कट-ऑफ की तारीख आने के बाद)। माइग्रेट किए गए डेटा का समर्थन किया जाना चाहिए आवश्यकता सभा के दौरान परिभाषित नई प्रणाली द्वारा।
सभी पुराने डेटा नई प्रणाली में उपलब्ध नहीं हो सकते हैं; हालाँकि, नए सिस्टम में पुराने डेटा का एक स्नैपशॉट उपलब्ध हो सकता है। यह डेटा सहमति के अनुसार उपलब्ध होना चाहिए।
ध्यान दें : उपरोक्त सूची संपूर्ण नहीं है। आवेदन के प्रकार के आधार पर, कुछ और चीजें हो सकती हैं जिन्हें आपको मान्य करना है या ऊपर की सभी चीजें लागू नहीं हो सकती हैं। इसलिए, सॉफ्टवेयर की गहन समझ, व्यावसायिक उद्देश्य, उपयोगकर्ता की अपेक्षाएं और वास्तु या हार्डवेयर निर्भरताएं व्यापक निकास मानदंडों को विकसित करना चाहिए।
गो-लाइव के लिए एक उदाहरण निकास मापदंड:
यह सिर्फ एक उदाहरण है। यह परियोजना से परियोजना में भिन्न हो सकता है।
- प्राथमिकता 1 के 100% दोष बंद हो गए हैं (गंभीरता महत्वपूर्ण और प्राथमिकता 1)
- प्राथमिकता 2 दोषों में से 90% बंद हैं (गंभीरता उच्च और प्राथमिकता 2) 10% दोषों के बाकी हिस्सों के लिए एक तार्किक समाधान उपलब्ध है। और, बाकी 10% दोषों को बंद करने के लिए एक योजना उपलब्ध है।
- उत्पादन परिनियोजन और पवित्रता जाँच सूची तैयार है।
- उत्पादन समर्थन टीम का गठन किया गया है और टिकटों को बंद करने के लिए तैयार है।
- प्राथमिकता वाले 3 दोषों में से 70% बंद हो जाते हैं और 30% कम दोषों को बंद करने के लिए योजना बनाई जाती है।
नोट करने के लिए कुछ बिंदु:
- कार्यक्रम की शुरुआत में ग्राहक और विक्रेता के बीच व्यावसायिक बैठकों के दौरान सभी गंभीरता और प्राथमिकता की परिभाषाएं तय की जाती हैं।
- सभी यूएटी दोषों को लॉग करने के बाद और अन्य सभी दोषों को बंद किया जा रहा है, यूएटी समन्वयक और बिजनेस प्रायोजक लंबित और खुले दोषों का जायजा लेने के लिए मिलते हैं। यदि डे -1 गो-लाइव के लिए आवश्यक सभी दोष बंद हो जाते हैं, तो व्यवसाय प्रायोजक गो-लाइव के लिए अपनी तत्परता देखते हैं और सॉफ्टवेयर को उत्पादन में लाते हैं।
निष्कर्ष के तौर पर
हमें उम्मीद है कि इस लेख ने आपको कुछ महत्वपूर्ण विचार के रूप में कुछ अंतर्दृष्टि प्रदान की है जो रॉक-ठोस निकास मानदंड बनाने में जाती है जो सॉफ़्टवेयर को प्रस्तुतियों में संभावित विफलताओं से बचाती है।
लेखक के बारे में: यह कृष्णन वेंकटरमण का एक अतिथि लेख है। सॉफ्टवेयर टेस्टिंग में उन्हें लगभग 18 साल का अनुभव है। उन्होंने कई बड़े और जटिल सॉफ्टवेयर परीक्षण परियोजनाओं पर काम किया है।
नीचे अपने प्रश्नों / टिप्पणियों को बेझिझक पोस्ट करें।
अनुशंसित पाठ
- सर्वश्रेष्ठ सॉफ्टवेयर परीक्षण उपकरण 2021 (क्यूए टेस्ट स्वचालन उपकरण)
- सॉफ्टवेयर परीक्षण क्यूए सहायक नौकरी
- सॉफ्टवेयर टेस्टिंग कोर्स: मुझे किस सॉफ्टवेयर टेस्टिंग इंस्टीट्यूट में शामिल होना चाहिए?
- अपने कैरियर के रूप में सॉफ्टवेयर परीक्षण चुनना
- सॉफ्टवेयर टेस्टिंग टेक्निकल कंटेंट राइटर फ्रीलांसर जॉब
- कुछ दिलचस्प सॉफ्टवेयर परीक्षण साक्षात्कार प्रश्न
- सॉफ्टवेयर परीक्षण पाठ्यक्रम प्रतिक्रिया और समीक्षा
- सॉफ्टवेयर परीक्षण मदद संबद्ध कार्यक्रम!