उपयोगकर्ता स्वीकृति परीक्षण (UAT) क्या है: एक पूर्ण गाइड

what is user acceptance testing

जानें कि उपयोगकर्ता स्वीकृति परीक्षण (UAT) क्या है, इसकी परिभाषा, प्रकार, चरण और उदाहरण के साथ:

एक नई अवधारणा को समझने की कोशिश करते समय मेरा नियम नंबर एक है: नाम हमेशा प्रासंगिक और अधिकतर शाब्दिक अर्थ वाला होता है (तकनीकी संदर्भ में)।

यह पता लगाना कि वह क्या है, इसकी प्रारंभिक समझ देगा और मुझे इसके साथ आरंभ करने में मदद करेगा।

वेब सेवाएं साक्षात्कार प्रश्न .net

=> पूरी टेस्ट प्लान ट्यूटोरियल सीरीज़ के लिए यहां क्लिक करें

आइए हम इस अवधारणा को परीक्षण के लिए रखते हैं।

=> सभी ट्यूटोरियल पढ़ें हमारी स्वीकृति परीक्षण श्रृंखला में।

आप क्या सीखेंगे:

• उपयोगकर्ता स्वीकृति परीक्षण क्या है?
  • जब यह प्रदर्शन किया है?
  • कौन करता है UAT?
  • उपयोगकर्ता स्वीकृति परीक्षण की आवश्यकता
  • उपयोगकर्ता स्वीकृति परीक्षण प्रक्रिया
  • यूएटी शासन
  • UAT टेस्ट प्लानिंग
  • उपयोगकर्ता स्वीकृति परीक्षण डिजाइन
  • परीक्षण निष्पादन
  • उपकरण और तरीके
  • चुस्त वातावरण में यूएटी
  • UAT टीम - भूमिकाएँ और जिम्मेदारियाँ
• यूएटी और शमन योजना की 7 चुनौतियां
• सिस्टम परीक्षण बनाम उपयोगकर्ता स्वीकृति परीक्षण
• निष्कर्ष
  • अनुशंसित पाठ

उपयोगकर्ता स्वीकृति परीक्षण क्या है?

हम जानते हैं कि परीक्षण क्या है, स्वीकृति का मतलब अनुमोदन या समझौता है। सॉफ़्टवेयर उत्पाद के संदर्भ में उपयोगकर्ता या तो सॉफ़्टवेयर का उपभोक्ता है या उस व्यक्ति का जिसने उससे अनुरोध किया है कि उसे उसके (क्लाइंट) के लिए बनाया जाए।

इसलिए, मेरे नियम का पालन करना - परिभाषा होगी:

उपयोगकर्ता स्वीकृति परीक्षण (UAT), जिसे बीटा या अंतिम-उपयोगकर्ता परीक्षण के रूप में भी जाना जाता है, यह निर्धारित करने के लिए उपयोगकर्ता या ग्राहक द्वारा सॉफ़्टवेयर का परीक्षण करने के रूप में परिभाषित किया जाता है कि इसे स्वीकार किया जा सकता है या नहीं। कार्यात्मक, प्रणाली और प्रतिगमन परीक्षण पूरा हो जाने के बाद यह अंतिम परीक्षण होता है।

इस परीक्षण का मुख्य उद्देश्य व्यवसाय की आवश्यकताओं के विरुद्ध सॉफ्टवेयर को मान्य करना है। यह सत्यापन अंतिम उपयोगकर्ताओं द्वारा किया जाता है जो व्यवसाय की आवश्यकताओं से परिचित हैं।

UAT, अल्फा और बीटा परीक्षण स्वीकृति परीक्षण के विभिन्न प्रकार हैं।

जैसा कि उपयोगकर्ता स्वीकृति परीक्षण अंतिम परीक्षण है जो सॉफ्टवेयर के लाइव होने से पहले किया जाता है, जाहिर है कि यह ग्राहक के लिए सॉफ्टवेयर का परीक्षण करने और मापने का अंतिम मौका है यदि यह उद्देश्य के लिए फिट है।

जब यह प्रदर्शन किया है?

उत्पाद के लाइव होने से पहले या उत्पाद की डिलीवरी स्वीकार होने से पहले यह आमतौर पर अंतिम चरण है। यह उत्पाद के पूरी तरह से परीक्षण करने के बाद किया जाता है (यानी सिस्टम परीक्षण के बाद ) का है।

कौन करता है UAT?

उपयोगकर्ता या ग्राहक - यह या तो कोई ऐसा व्यक्ति हो सकता है जो कोई उत्पाद खरीद रहा हो (वाणिज्यिक सॉफ्टवेयर के मामले में) या कोई ऐसा व्यक्ति जिसके पास सॉफ़्टवेयर सेवा प्रदाता या एंड-यूज़र द्वारा सॉफ़्टवेयर कस्टम-बिल्ड किया गया हो यदि सॉफ़्टवेयर उन्हें उपलब्ध कराया जाता है समय से पहले और जब उनकी प्रतिक्रिया मांगी जाती है।

टीम में बीटा परीक्षक शामिल हो सकते हैं या ग्राहक को संगठन के प्रत्येक समूह से आंतरिक रूप से यूएटी सदस्यों का चयन करना चाहिए ताकि प्रत्येक और हर उपयोगकर्ता भूमिका के अनुसार परीक्षण किया जा सके।

उपयोगकर्ता स्वीकृति परीक्षण की आवश्यकता

डेवलपर्स और कार्यात्मक परीक्षक तकनीकी लोग हैं जो सॉफ्टवेयर के खिलाफ मान्य हैं कार्यात्मक विनिर्देशों । वे अपने ज्ञान के अनुसार आवश्यकताओं की व्याख्या करते हैं और सॉफ़्टवेयर का विकास / परीक्षण करते हैं (यहां डोमेन ज्ञान का महत्व है)।

यह सॉफ्टवेयर कार्यात्मक विशिष्टताओं के अनुसार पूरा हो गया है, लेकिन कुछ व्यावसायिक आवश्यकताएं और प्रक्रियाएं हैं जो केवल अंत-उपयोगकर्ताओं के लिए जानी जाती हैं या तो संवाद करने या गलत व्याख्या करने से चूक जाती हैं।

यह परीक्षण यह प्रमाणित करने में महत्वपूर्ण भूमिका निभाता है कि बाजार के उपयोग के लिए सॉफ्टवेयर जारी करने से पहले सभी व्यावसायिक आवश्यकताओं को पूरा किया जाए या नहीं। लाइव डेटा और वास्तविक उपयोग के मामलों का उपयोग इस परीक्षण को रिलीज़ चक्र का एक महत्वपूर्ण हिस्सा बनाता है।

कई व्यवसाय जिन्हें रिलीज़ के बाद के मुद्दों के कारण बड़ा नुकसान उठाना पड़ा, वे एक सफल उपयोगकर्ता स्वीकृति टेस्ट के महत्व को जानते हैं। रिलीज के बाद दोषों को ठीक करने की लागत पहले से तय करने की तुलना में कई गुना अधिक है।

क्या UAT वास्तव में आवश्यक है?

प्रणाली के भार का प्रदर्शन करने के बाद, एकीकरण और प्रतिगमन परीक्षण एक इस परीक्षण की आवश्यकता के बारे में आश्चर्य होगा। वास्तव में, यह परियोजना का सबसे महत्वपूर्ण चरण है क्योंकि यह वह समय है, जिस पर उपयोगकर्ता वास्तव में सिस्टम का उपयोग करने जा रहे हैं, यह सिस्टम को उसके उद्देश्य के लिए मान्य होगा।

यूएटी एक परीक्षण चरण है जो काफी हद तक अंत-उपयोगकर्ताओं के दृष्टिकोण और अंत-उपयोगकर्ताओं का प्रतिनिधित्व करने वाले विभाग के डोमेन ज्ञान पर निर्भर करता है।

तथ्य की बात के रूप में, यह वास्तव में व्यावसायिक टीमों के लिए उपयोगी होगा, अगर वे परियोजना में काफी पहले शामिल थे, ताकि वे अपने विचार और योगदान प्रदान कर सकें जो वास्तविक दुनिया में प्रणाली के प्रभावी उपयोग में मदद करेंगे।

उपयोगकर्ता स्वीकृति परीक्षण प्रक्रिया

इस प्रक्रिया को समझने का सबसे आसान तरीका यह है कि इसे एक स्वायत्त परीक्षण परियोजना के रूप में सोचा जाए - जिसका अर्थ है, इसमें योजना, डिजाइन और निष्पादन चरण होंगे।

नियोजन चरण शुरू होने से पहले निम्नलिखित आवश्यक हैं:

(1) प्रमुख स्वीकृति मानदंड इकट्ठा करें

सरल शब्दों में, स्वीकृति मानदंड उन चीजों की एक सूची है जो उत्पाद को स्वीकार करने से पहले मूल्यांकन करने जा रहे हैं।

ये 2 प्रकार के हो सकते हैं:

(i) अनुप्रयोग कार्यशीलता या व्यवसाय संबंधी

आदर्श रूप से, सभी प्रमुख व्यावसायिक कार्यक्षमता को मान्य किया जाना चाहिए, लेकिन समय सहित विभिन्न कारणों के कारण, यह सब करना व्यावहारिक नहीं है। इसलिए, ग्राहक के साथ एक या दो बैठक या इस परीक्षण में शामिल होने वाले उपयोगकर्ता हमें इस बात का अंदाजा लगा सकते हैं कि परीक्षण कितना शामिल होने वाला है और किन पहलुओं का परीक्षण होने वाला है।

(ii) संविदात्मक - हम इसमें नहीं जा रहे हैं और इस सब में क्यूए टीम की भागीदारी लगभग कुछ भी नहीं है। एसडीएलसी शुरू होने से पहले ही तैयार किए गए प्रारंभिक अनुबंध की समीक्षा की जाती है और अनुबंध के सभी पहलुओं को वितरित किया गया है या नहीं इस पर एक समझौता किया जाता है।

हम केवल एप्लिकेशन कार्यक्षमता पर ध्यान केंद्रित करने जा रहे हैं।

# 2) क्यूए की भागीदारी के दायरे को परिभाषित करें।

QA टीम की भूमिका निम्नलिखित में से एक है:

(i) कोई समावेश नहीं - यह बहुत दुर्लभ है।

(ii) इस परीक्षण में सहायता - सबसे आम। इस मामले में, हमारी भागीदारी यूएटी उपयोगकर्ताओं को प्रशिक्षण का उपयोग करने के तरीके पर प्रशिक्षण दे सकती है और इस परीक्षण के दौरान स्टैंडबाय पर हो सकती है ताकि हम सुनिश्चित कर सकें कि हम किसी भी कठिनाई के मामले में उपयोगकर्ताओं की मदद कर सकते हैं। या कुछ मामलों में, स्टैंडबाय और सहायता पर होने के अलावा, हम उनकी प्रतिक्रियाओं को साझा कर सकते हैं और परिणाम या लॉग बग आदि को रिकॉर्ड कर सकते हैं, जबकि उपयोगकर्ता वास्तविक परीक्षण करते हैं।

(iii) UAT और वर्तमान परिणाम प्रस्तुत करें - यदि ऐसा है, तो उपयोगकर्ता AUT के उन क्षेत्रों को इंगित करेंगे, जिनका वे मूल्यांकन करना चाहते हैं और मूल्यांकन स्वयं QA टीम द्वारा किया जाता है। एक बार किए जाने के बाद, परिणाम ग्राहकों / उपयोगकर्ताओं को प्रस्तुत किए जाते हैं और वे इस बात पर निर्णय लेंगे कि जो परिणाम उनके हाथ में हैं वे पर्याप्त हैं या नहीं और ऑटो को स्वीकार करने के लिए उनकी अपेक्षाओं के अनुरूप हैं। निर्णय कभी भी क्यूए टीम का नहीं है।

हाथ पर मामले के आधार पर, हम तय करते हैं कि कौन सा दृष्टिकोण सबसे अच्छा है।

प्राथमिक उद्देश्य और उम्मीदें:

आमतौर पर, यूएटी एक विषय विशेषज्ञ (एसएमई) और / या एक व्यावसायिक उपयोगकर्ता द्वारा किया जाता है, जो परीक्षण के तहत एक प्रणाली का मालिक या ग्राहक हो सकता है। सिस्टम परीक्षण चरण के समान, यूएटी चरण को बंद करने के लिए लाने से पहले धार्मिक चरणों को भी शामिल किया गया है।

प्रत्येक यूएटी चरण की प्रमुख गतिविधियों को नीचे परिभाषित किया गया है:

यूएटी शासन

सिस्टम टेस्टिंग के समान, यूएटी के लिए प्रभावी प्रशासन को लागू किया जाता है ताकि यह सुनिश्चित किया जा सके कि निर्धारित एंट्री और एक्जिट मानदंड (** के नीचे प्रदान किए गए) के साथ मजबूत गुणवत्ता वाले फाटक हों।

** कृपया ध्यान दें कि यह केवल एक मार्गदर्शन है। यह परियोजना की जरूरतों और आवश्यकताओं के आधार पर संशोधित किया जा सकता है।

UAT टेस्ट प्लानिंग

इस प्रक्रिया के साथ के रूप में लगभग एक ही है नियमित परीक्षण योजना सिस्टम चरण में।

अधिकांश परियोजनाओं में सबसे आम दृष्टिकोण दोनों प्रणाली और यूएटी परीक्षण चरणों के लिए एक साथ योजना बनाना है। नमूने के साथ UAT परीक्षण योजना के बारे में अधिक जानकारी के लिए, कृपया संलग्न परीक्षण योजना दस्तावेज़ UAT अनुभाग देखें।

उपयोगकर्ता स्वीकृति परीक्षण योजना

(यह वही है जो आपको क्यूए प्रशिक्षण श्रृंखला के लिए हमारी साइट पर मिलेगा)।

नीचे दी गई छवि पर क्लिक करें और विभिन्न स्वरूपों में परीक्षण योजना दस्तावेज़ नमूना खोजने के लिए नीचे स्क्रॉल करें। उस टेम्पलेट में UAT सेक्शन को चेक करें।

दिनांक, पर्यावरण, अभिनेता (जो), संचार प्रोटोकॉल, भूमिकाएं और जिम्मेदारियां, टेम्पलेट, परिणाम और उनकी विश्लेषण प्रक्रिया, प्रवेश-निकास मानदंड - यह सब और जो कुछ भी प्रासंगिक है, वह यूएटी परीक्षण योजना में मिलेगा।

क्यूए टीम भाग ले रही है या नहीं, इस परीक्षा में आंशिक रूप से भाग ले रही है या नहीं, इस चरण की योजना बनाना और यह सुनिश्चित करना हमारा काम है कि सब कुछ ध्यान में रखा जाए।

=> यहाँ एक उपयोगकर्ता स्वीकृति परीक्षण योजना नमूना दस्तावेज है

उपयोगकर्ता स्वीकृति परीक्षण डिजाइन

उपयोगकर्ताओं से एकत्रित स्वीकृति मानदंड इस चरण में उपयोग किए जाते हैं। नमूने नीचे दिखाए गए अनुसार दिख सकते हैं।

(ये अंश हैं सीएसटीई CBOK । यह इस परीक्षण के बारे में उपलब्ध सर्वोत्तम संदर्भों में से एक है।)

उपयोगकर्ता स्वीकृति परीक्षण टेम्प्लेट:

मानदंडों के आधार पर, हम (QA टीम) उपयोगकर्ताओं को UAT परीक्षण मामलों की एक सूची देते हैं। ये परीक्षण मामले हमारे नियमित प्रणाली परीक्षण मामलों से अलग नहीं हैं। वे केवल एक सबसेट हैं क्योंकि हम सभी अनुप्रयोगों का विरोध करते हैं, सिर्फ प्रमुख कार्यात्मक क्षेत्रों में।

इन के अलावा, डेटा, परीक्षण के परिणामों को रिकॉर्ड करने के लिए टेम्पलेट, प्रशासनिक प्रक्रिया, दोष तंत्र लॉगिंग, आदि, हम अगले चरण में जाने से पहले जगह में होना चाहिए।

परीक्षण निष्पादन

आमतौर पर, जब संभव होता है, तो यह परीक्षण एक सम्मेलन या एक वार रूम सेट की तरह होता है जहां उपयोगकर्ता, पीएम, क्यूए टीम के प्रतिनिधि सभी एक या दो दिन के लिए एक साथ बैठते हैं और सभी स्वीकृति परीक्षण मामलों के माध्यम से काम करते हैं।

या क्यूए टीम द्वारा परीक्षण करने के मामले में, हम ऑटो पर परीक्षण मामलों को चलाते हैं।

एक बार सभी परीक्षण चलाए जाते हैं और परिणाम हाथ में होते हैं, स्वीकृति का निर्णय से बना। यह भी कहा जाता है गो / नो-गो निर्णय । यदि उपयोगकर्ता इसे संतुष्ट करते हैं, तो यह एक और नहीं है।

स्वीकृति निर्णय पर पहुंचना आम तौर पर इस चरण का अंत है।

उपकरण और तरीके

आमतौर पर, इस परीक्षण चरण के दौरान उपयोग किए जाने वाले सॉफ़्टवेयर उपकरण कार्यात्मक परीक्षण करते समय उपयोग किए जाने वाले टूल के समान होते हैं।

उपकरण:

चूंकि इस चरण में एप्लिकेशन के पूर्ण अंत से लेकर अंतिम प्रवाह को मान्य करना शामिल है, इसलिए इस सत्यापन को पूरी तरह से स्वचालित करने के लिए एक उपकरण होना मुश्किल हो सकता है। हालाँकि, कुछ हद तक, हम सिस्टम परीक्षण के दौरान विकसित स्वचालित स्क्रिप्ट का लाभ उठाने में सक्षम होंगे।

सिस्टम परीक्षण के समान, उपयोगकर्ता परीक्षण प्रबंधन और दोष प्रबंधन उपकरण जैसे QC, JIRA, आदि का भी उपयोग करेंगे। इन उपकरणों को उपयोगकर्ता स्वीकृति चरण के लिए संचयी डेटा के लिए कॉन्फ़िगर किया जा सकता है।

एंगुलरज ऐप्स के लिए टेस्टिंग फ्रेम टू एंड टेस्टिंग फ्रेमवर्क एंड

तरीके:

हालांकि पारंपरिक कार्यप्रणाली जैसे कि विशिष्ट व्यवसाय उपयोगकर्ता उत्पाद का यूएटी प्रदर्शन कर रहे हैं, आज भी वास्तव में वैश्विक दुनिया में प्रासंगिक है, उपयोगकर्ता स्वीकृति परीक्षण को कभी-कभी उत्पाद के आधार पर विभिन्न देशों में विभिन्न ग्राहकों को शामिल करना पड़ता है।

उदाहरण के लिए, ई-कॉमर्स वेबसाइट का उपयोग दुनिया भर के ग्राहकों द्वारा किया जाएगा। इस तरह के परिदृश्यों में, भीड़ परीक्षण सबसे अच्छा व्यवहार्य विकल्प होगा।

भीड़ का परीक्षण एक कार्यप्रणाली है जहां दुनिया भर के लोग भाग ले सकते हैं और उत्पाद के उपयोग को मान्य कर सकते हैं और सुझाव और सिफारिशें दे सकते हैं।

भीड़ परीक्षण प्लेटफ़ॉर्म का निर्माण और उपयोग कई संगठनों द्वारा किया जा रहा है। एक वेबसाइट या एक उत्पाद जिसे भीड़ की जांच करने की आवश्यकता होती है, उसे प्लेटफ़ॉर्म में होस्ट किया जाता है और ग्राहक सत्यापन करने के लिए खुद को नामांकित कर सकते हैं। प्रदान किए गए फीडबैक का विश्लेषण और प्राथमिकता दी जाती है।

भीड़ परीक्षण पद्धति अधिक कारगर साबित हो रही है क्योंकि दुनिया भर में ग्राहक की नब्ज आसानी से समझी जा सकती है।

चुस्त वातावरण में यूएटी

चंचल वातावरण प्रकृति में अधिक गतिशील है। एक फुर्तीली दुनिया में, व्यावसायिक उपयोगकर्ता पूरे प्रोजेक्ट स्प्रिंट में शामिल होंगे और उनसे फीडबैक लूप के आधार पर परियोजना को बढ़ाया जाएगा।

परियोजना की शुरुआत में, व्यावसायिक उपयोगकर्ता आवश्यकता के लिए मुख्य हितधारक होंगे, जिससे उत्पाद बैकलॉग को अद्यतन किया जा सके। प्रत्येक स्प्रिंट के अंत के दौरान, व्यावसायिक उपयोगकर्ता स्प्रिंट डेमो में भाग लेंगे और कोई भी प्रतिक्रिया प्रदान करने के लिए उपलब्ध होंगे।

इसके अलावा, स्प्रिंट पूरा होने से पहले एक यूएटी चरण की योजना बनाई जाएगी जहां व्यवसाय उपयोगकर्ता अपना सत्यापन करेंगे।

स्प्रिंट डेमो और स्प्रिंट यूएटी के दौरान प्राप्त होने वाले फीडबैक को मिलाया जाता है और उत्पाद बैकलॉग में वापस जोड़ा जाता है जिसे लगातार समीक्षा और प्राथमिकता दी जाती है। इस प्रकार एक फुर्तीली दुनिया में, व्यावसायिक उपयोगकर्ता परियोजना के अधिक करीब हैं और वे पारंपरिक जलप्रपात परियोजनाओं के विपरीत इसके उपयोग के लिए अधिक बार मूल्यांकन करते हैं।

UAT टीम - भूमिकाएँ और जिम्मेदारियाँ

एक विशिष्ट यूएटी संगठन में निम्नलिखित भूमिकाएं और जिम्मेदारियां होंगी। यूएटी टीम को परियोजना प्रबंधक, विकास और परीक्षण टीमों द्वारा उनकी आवश्यकताओं के आधार पर समर्थन दिया जाएगा।

यूएटी और शमन योजना की 7 चुनौतियां

इससे कोई फर्क नहीं पड़ता कि आप एक बिलियन-डॉलर रिलीज़ या स्टार्टअप टीम का हिस्सा हैं, आपको एंड-यूज़र के लिए सफल सॉफ़्टवेयर देने के लिए इन सभी चुनौतियों से पार पाना चाहिए।

# 1) पर्यावरण सेटअप और परिनियोजन प्रक्रिया:

कार्यात्मक परीक्षण टीम द्वारा उपयोग किए जाने वाले एक ही वातावरण में इस परीक्षण को करने से निश्चित रूप से वास्तविक दुनिया के उपयोग के मामलों की अनदेखी हो जाएगी। इसके अलावा, प्रदर्शन परीक्षण जैसी महत्वपूर्ण परीक्षण गतिविधियों को अपूर्णता के साथ एक परीक्षण वातावरण पर नहीं किया जा सकता है परीक्षण डेटा ।

इस परीक्षण के लिए एक अलग उत्पादन जैसा वातावरण स्थापित किया जाना चाहिए।

एक बार जब यूएटी पर्यावरण को परीक्षण वातावरण से अलग कर दिया जाता है, तो आपको रिलीज चक्र को प्रभावी ढंग से नियंत्रित करने की आवश्यकता होती है। अनियंत्रित रिलीज़ चक्र परीक्षण और UAT वातावरण पर विभिन्न सॉफ़्टवेयर संस्करणों को जन्म दे सकता है। जब नवीनतम संस्करण पर सॉफ़्टवेयर का परीक्षण नहीं किया जाता है तो मूल्यवान स्वीकृति परीक्षण समय बर्बाद हो जाता है।

इस बीच, गलत सॉफ्टवेयर संस्करण पर अंक ट्रैकिंग के लिए आवश्यक समय अधिक है।

# 2) परीक्षण योजना:

यह परीक्षण आवश्यकता विश्लेषण और डिजाइन चरण में एक स्पष्ट स्वीकृति परीक्षण योजना के साथ किया जाना चाहिए।

रणनीति नियोजन में, निष्पादन के लिए वास्तविक दुनिया के उपयोग मामलों के सेट की पहचान की जानी चाहिए। इस परीक्षण के लिए परीक्षण के उद्देश्यों को परिभाषित करना बहुत महत्वपूर्ण है क्योंकि इस परीक्षण चरण में बड़े अनुप्रयोगों के लिए पूर्ण परीक्षण निष्पादन संभव नहीं है। पहले महत्वपूर्ण व्यावसायिक उद्देश्यों को प्राथमिकता देकर परीक्षण किया जाना चाहिए।

यह परीक्षण परीक्षण चक्र के अंत में किया जाता है। जाहिर है, यह सॉफ्टवेयर रिलीज के लिए सबसे महत्वपूर्ण अवधि है। विकास और परीक्षण के किसी भी अंतिम चरण में देरी UAT समय खाएगी।

अनुचित परीक्षण योजना, सबसे खराब मामलों में, सिस्टम परीक्षण और यूएटी के बीच एक ओवरलैप की ओर जाता है। कम समय और समय सीमा को पूरा करने के दबाव के कारण, कार्यात्मक परीक्षण पूरा न होने पर भी सॉफ्टवेयर को इस वातावरण में तैनात किया जाता है। ऐसी स्थितियों में इस परीक्षण के मुख्य लक्ष्यों को प्राप्त नहीं किया जा सकता है।

UAT परीक्षण योजना तैयार की जानी चाहिए और इस परीक्षण को शुरू करने से पहले टीम को अच्छी तरह से सूचित किया जाना चाहिए। यह उन्हें परीक्षण की योजना बनाने, परीक्षण मामलों को लिखने और स्क्रिप्ट का परीक्षण करने और UAT वातावरण बनाने में मदद करेगा।

# 3) घटनाओं / दोषों के रूप में नई व्यावसायिक आवश्यकताओं को संभालना:

आवश्यकताओं में अस्पष्टता यूएटी चरण में फंस जाती है। UAT परीक्षकों को अस्पष्ट आवश्यकताओं के कारण उत्पन्न होने वाली समस्याओं का पता चलता है (संपूर्ण UI को देखने के लिए जो आवश्यकता के चरण में उपलब्ध नहीं था) और इसे एक दोष के रूप में लॉग इन करें।

ग्राहक को उम्मीद है कि ये मौजूदा रिलीज़ में परिवर्तन अनुरोधों के लिए समय पर विचार किए बिना तय किए जाएंगे। यदि इन अंतिम-मिनट के परिवर्तनों पर परियोजना प्रबंधन द्वारा समय पर निर्णय नहीं लिया जाता है, तो इससे रिलीज विफलता हो सकती है।

# 4) बिना व्यावसायिक ज्ञान के अकुशल परीक्षक या परीक्षक:

जब कोई स्थायी टीम नहीं होती है, तो कंपनी विभिन्न आंतरिक विभागों से यूएटी कर्मचारियों का चयन करती है।

भले ही कर्मचारी व्यवसाय की आवश्यकताओं से अच्छी तरह परिचित हों, या यदि वे विकसित हो रही नई आवश्यकताओं के लिए प्रशिक्षित नहीं हैं, तो वे प्रभावी यूएटी का प्रदर्शन नहीं कर सकते हैं। इसके अलावा, एक गैर-तकनीकी व्यवसाय टीम को परीक्षण मामलों को निष्पादित करने में कई तकनीकी कठिनाइयों का सामना करना पड़ सकता है।

इस बीच, यूएटी चक्र के अंत में परीक्षक असाइन करना परियोजना में कोई मूल्य नहीं जोड़ता है। यूएटी कर्मचारियों को प्रशिक्षित करने के लिए बहुत कम समय यूएटी की सफलता की संभावना को बढ़ा सकता है।

# 5) अनुचित संचार चैनल:

दूरस्थ विकास, परीक्षण और UAT टीम के बीच संचार अधिक कठिन है। ईमेल संचार अक्सर बहुत मुश्किल होता है जब आपके पास एक ऑफशोर टेक टीम होती है। घटना की रिपोर्टों में एक छोटी सी अस्पष्टता एक दिन के लिए इसके सुधार में देरी कर सकती है।

प्रभावी टीम सहयोग के लिए उचित योजना और प्रभावी संचार महत्वपूर्ण हैं। प्रोजेक्ट टीमों को दोषों और प्रश्नों को लॉग करने के लिए वेब-आधारित टूल का उपयोग करना चाहिए। यह समान रूप से वर्कलोड को वितरित करने और डुप्लिकेट मुद्दों की रिपोर्टिंग से बचने में मदद करेगा।

# 6) यह परीक्षण करने के लिए कार्यात्मक परीक्षण टीम से पूछना:

यूएटी प्रदर्शन करने के लिए कार्यात्मक परीक्षण टीम से पूछने से बदतर स्थिति नहीं है।

ग्राहक संसाधनों की कमी के कारण टेस्ट टीम में अपनी जिम्मेदारी को छोड़ देते हैं। इस परीक्षण का पूरा उद्देश्य ऐसे मामलों में समझौता हो जाता है। एक बार सॉफ्टवेयर लाइव हो जाने के बाद, एंड-यूजर्स उन मुद्दों को जल्दी से हल कर देंगे जिन्हें कार्यात्मक परीक्षकों द्वारा वास्तविक दुनिया के परिदृश्य के रूप में नहीं माना जाता है।

इसका एक समाधान व्यावसायिक ज्ञान रखने वाले समर्पित और कुशल परीक्षकों को यह परीक्षण प्रदान करना है।

# 7) दोष खेल

कभी-कभी व्यावसायिक उपयोगकर्ता सॉफ़्टवेयर को अस्वीकार करने के कारणों को खोजने का प्रयास करते हैं। यह दिखाने के लिए कि वे कितने श्रेष्ठ हैं या व्यवसाय टीम में सम्मान पाने के लिए विकास और परीक्षण टीम को दोषी ठहराते हैं, यह उनकी निष्ठा हो सकती है। ऐसा बहुत कम होता है लेकिन आंतरिक राजनीति वाली टीमों में होता है।

ऐसी स्थितियों से निपटना बहुत मुश्किल है। हालांकि, व्यावसायिक टीम के साथ सकारात्मक संबंध बनाने से निश्चित रूप से दोष के खेल से बचने में मदद मिलेगी।

मुझे उम्मीद है कि ये दिशा-निर्देश निश्चित रूप से विभिन्न चुनौतियों से पार पाकर एक सफल उपयोगकर्ता स्वीकृति योजना को क्रियान्वित करने में आपकी मदद करेंगे। उचित योजना, संचार, निष्पादन और प्रेरित टीम सफल उपयोगकर्ता स्वीकृति परीक्षण की कुंजी है।

सिस्टम परीक्षण बनाम उपयोगकर्ता स्वीकृति परीक्षण

परीक्षण टीम की भागीदारी परियोजना में आवश्यकता विश्लेषण चरण से काफी पहले शुरू होती है।

परियोजना के जीवन चक्र के माध्यम से सभी, परियोजना के लिए किसी प्रकार का सत्यापन किया जाता है, अर्थात्। स्थैतिक परीक्षण , यूनिट टेस्टिंग, सिस्टम टेस्टिंग, इंटीग्रेशन टेस्टिंग, एंड टू एंड टेस्टिंग या रिग्रेशन टेस्टिंग। यह हमें UAT चरण में किए गए परीक्षण के बारे में बेहतर समझने के लिए छोड़ देता है और यह पहले किए गए अन्य परीक्षण से कितना अलग है।

यद्यपि हम एसआईटी और यूएटी में अंतर देखते हैं, यह महत्वपूर्ण है कि हम तालमेल का लाभ उठाएं लेकिन फिर भी दोनों चरणों के बीच स्वतंत्रता बनाए रखें जिससे बाजार में तेजी से समय मिल सके।

निष्कर्ष

# 1) UAT पेज, फ़ील्ड या बटन के बारे में नहीं है। बुनियादी कल्पना इस परीक्षण के शुरू होने से पहले ही यह है कि मूल सामग्री का परीक्षण किया जाता है और ठीक काम कर रहा है। ईश्वर न करे, उपयोगकर्ताओं को एक बग जितना बुनियादी लगता है - यह क्यूए टीम के लिए बहुत बुरी खबर का एक टुकड़ा है। :(

#दो) यह परीक्षण उस इकाई के बारे में है जो व्यवसाय में प्राथमिक तत्व है।

मैं आपको एक उदाहरण देता हूं: यदि AUT एक टिकटिंग सिस्टम है, तो UAT के बारे में नहीं जा रहा है, एक पेज खोलने वाले मेनू के लिए खोज कर रहा है। यह टिकट और उनके आरक्षण के बारे में है, यह बताता है कि यह प्रणाली के माध्यम से अपनी यात्रा कर सकता है, आदि।

एक और उदाहरण, यदि साइट एक कार डीलरशिप साइट है, तो फोकस 'कार और उसकी बिक्री' पर है और वास्तव में साइट नहीं है। इसलिए, मुख्य व्यवसाय वह है जो सत्यापित और मान्य है और व्यवसाय मालिकों की तुलना में इसे करना बेहतर है। यही कारण है कि यह परीक्षण सबसे अधिक समझ में आता है जब ग्राहक एक बड़ी सीमा तक शामिल होता है।

# 3) यूएटी भी अपने मूल में परीक्षण का एक रूप है जिसका अर्थ है इस चरण में कुछ बगों की पहचान करने का एक अच्छा मौका है । ऐसा कभी-कभी होता है। इस तथ्य के अलावा कि यह क्यूए टीम पर एक प्रमुख वृद्धि है, यूएटी के कीड़े आमतौर पर बैठने और चर्चा करने के लिए एक बैठक का मतलब है कि इस परीक्षण का पालन करने के लिए उन्हें कैसे संभालना है और आमतौर पर ठीक होने का समय नहीं है।

निर्णय या तो यह होगा:

• गो-लाइव तिथि को पुश करें, पहले समस्या को ठीक करें और फिर आगे बढ़ें।
• बग को वैसे ही छोड़ दें।
• इसे भविष्य के रिलीज के लिए परिवर्तन अनुरोध के एक भाग के रूप में देखें।

# 4) यूएटी को अल्फा और बीटा परीक्षण के रूप में वर्गीकृत किया गया है, लेकिन सेवा आधारित उद्योग में विशिष्ट सॉफ्टवेयर विकास परियोजनाओं के संदर्भ में यह वर्गीकरण महत्वपूर्ण नहीं है।

• अल्फा परीक्षण जब UAT को सॉफ़्टवेयर बिल्डर के वातावरण में किया जाता है और शेल्फ सॉफ़्टवेयर से व्यावसायिक के संदर्भ में अधिक महत्वपूर्ण होता है।
• बीटा परीक्षण जब UAT को उत्पादन वातावरण या क्लाइंट के वातावरण में किया जाता है। यह ग्राहक-सामना वाले अनुप्रयोगों के लिए अधिक सामान्य है। यहां के उपयोगकर्ता इस संदर्भ में आपके और मेरे जैसे वास्तविक ग्राहक हैं।

# 5) अधिकांश समय एक नियमित सॉफ्टवेयर विकास परियोजना में, UAT को किया जाता है क्यूए वातावरण यदि कोई मंचन या UAT वातावरण नहीं है।

संक्षेप में, यह पता लगाने का सबसे अच्छा तरीका है कि क्या आपका उत्पाद स्वीकार्य है और उद्देश्य के लिए फिट है, वास्तव में इसे उपयोगकर्ताओं के सामने रखना है।

संगठन पहुंचाने के चुस्त तरीके से हो रहे हैं, व्यावसायिक उपयोगकर्ता अधिक शामिल हो रहे हैं और परियोजनाओं को फीडबैक लूप के माध्यम से बढ़ाया और वितरित किया जा रहा है। सभी किया जा रहा है, उपयोगकर्ता स्वीकृति चरण कार्यान्वयन और उत्पादन में प्रवेश करने के लिए द्वार के रूप में माना जाता है।

c ++ रेगेक्स मैच उदाहरण

आपका UAT अनुभव क्या था? क्या आप स्टैंडबाय पर थे या आपने अपने उपयोगकर्ताओं के लिए परीक्षण किया था? क्या उपयोगकर्ताओं को कोई समस्या मिली? यदि हाँ, तो आपने उनके साथ कैसे व्यवहार किया?

=> इस श्रृंखला में सभी ट्यूटोरियल भी पढ़ें

=> पूरी टेस्ट प्लान ट्यूटोरियल सीरीज़ के लिए यहां जाएं

अनुशंसित पाठ

• अल्फा परीक्षण और बीटा परीक्षण (एक पूर्ण गाइड)
• स्वीकृति परीक्षण क्या है (एक पूर्ण गाइड)
• वेरिफिकेशन टेस्टिंग (BVT टेस्टिंग) कम्प्लीट गाइड का निर्माण करें
• कार्यात्मक परीक्षण बनाम गैर-कार्यात्मक परीक्षण
• सर्वश्रेष्ठ सॉफ्टवेयर परीक्षण उपकरण 2021 (क्यूए टेस्ट स्वचालन उपकरण)
• सॉफ्टवेयर परीक्षण के प्रकार: विभिन्न परीक्षण प्रकार विवरण के साथ
• ETL परीक्षण डेटा वेयरहाउस परीक्षण ट्यूटोरियल (एक पूर्ण गाइड)
• जीयूआई परीक्षण ट्यूटोरियल: एक पूर्ण उपयोगकर्ता इंटरफ़ेस (यूआई) परीक्षण गाइड