Dynamics 365 UAT: एक व्यावहारिक गाइड

Dynamics 365 में UAT कब चाहिए

यूज़र एक्सेप्टेंस टेस्ट एक सवाल का जवाब देता है: क्या बिज़नेस Dynamics 365 के इस वर्ज़न में अपना काम कर सकता है? जो लोग यह काम करते हैं, वही इसे अपने शब्दों में टेस्ट करते हैं, प्रोडक्शन तक पहुँचने से पहले। इन मौकों पर आपको इसकी ज़रूरत होती है।

• गो-लाइव। पहला Dynamics 365 Sales या Customer Service, या किसी दूसरे CRM से आना।
• नया ऐप या मॉड्यूल। Sales के साथ Customer Service, किसी टीम के लिए नया model-driven ऐप, कस्टमर पोर्टल, या Copilot फ़ीचर जिन्हें आप चालू करते हैं।
• बड़ा बदलाव। ERP के साथ नया इंटीग्रेशन, या केस रूट करने का नया तरीका।
• Microsoft के अपडेट। Microsoft अब Dynamics 365 के बदलावों को साल में दो release waves में एक साथ नहीं लाता। नए फ़ीचर और बदलाव पूरे साल आते रहते हैं। Release plans अक्टूबर 2026 में आर्काइव कर दिए गए; जो आने वाला है वह अब Microsoft roadmap में aka.ms/AIatWorkRoadmap पर है। कोई भी अपडेट आपके सिस्टम के काम करने का तरीका बदल सकता है, भले ही आपने खुद कुछ न बदला हो।

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

एनवायरनमेंट

प्रोडक्शन में कभी टेस्ट न करें। Power Platform व्यवस्थापन केंद्र में हर परिवेश का एक प्रकार होता है। UAT के लिए आपको सैंडबॉक्स चाहिए।

प्रोडक्शन की कॉपी

असली हालात के सबसे करीब आप सैंडबॉक्स परिवेश में प्रोडक्शन की कॉपी से पहुँचते हैं। परिवेश कॉपी करते समय आप चुनते हैं कि साथ में क्या आए:

• Everything: अनुकूलन, स्कीमा और पूरा डेटा। प्रोडक्शन के सबसे करीब, लेकिन इसमें असली कस्टमर डेटा और आपके यूज़र का बनाया हर रिकॉर्ड होता है।
• Customizations and schemas only: बिना डेटा के कॉन्फ़िगरेशन। अपना टेस्ट डेटा आप बाद में लोड करते हैं।

कॉपी लक्ष्य परिवेश की हर चीज़ को बदल देती है, इसलिए इसे UAT से पहले बनाएँ, उसके दौरान कभी नहीं। उसके बाद इंटीग्रेशन और Power Automate प्रवाहों को प्रोडक्शन नहीं, टेस्ट सिस्टम की ओर करें, मेलबॉक्स जाँचें, और तैयार होने पर परिवेश को व्यवस्थापन मोड से बाहर निकालें।

समाधान और बिल्ड

प्रोजेक्ट के बदलाव UAT परिवेश तक समाधानों के रूप में पहुँचते हैं। उन्हें प्रबंधित समाधान के रूप में इम्पोर्ट करें, पाइपलाइन हो तो उसके ज़रिए, ताकि UAT परिवेश को ठीक वही मिले जो बाद में प्रोडक्शन को मिलेगा।

• तय कर लें कि टेस्टिंग चलते समय समाधान कब इम्पोर्ट होंगे, जैसे दिन में एक बार ट्राइएज के बाद। टेस्ट के बीच में हुआ इम्पोर्ट टेस्टर के सामने की स्क्रीन बदल सकता है।
• लिखें कि UAT परिवेश में कौन-से समाधान और वर्ज़न हैं। समाधान का वर्ज़न नंबर वह बिल्ड है जिसे आप टेस्ट करते हैं, और हर इश्यू और रीटेस्ट किसी एक बिल्ड से जुड़ा होता है।

टेस्ट डेटा

जब डेटा तैयार नहीं होता तो टेस्टरों के घंटों बर्बाद होते हैं। पहले टेस्ट डे से पहले इसे तैयार करें:

• हर तरह के कस्टमर के लिए अकाउंट और संपर्क जिन्हें आप टेस्ट करते हैं, सही owner और व्यवसाय इकाई के साथ।
• उत्पाद और मूल्य सूचियाँ। किसी उत्पाद को सही कीमत पर जोड़ने से पहले उसका मूल्य सूची आइटम होना चाहिए, और सेल्स रिप्रेज़ेंटेटिव के इस्तेमाल से पहले उसे प्रकाशित करना होता है। जाँचें कि हर सेल्स टीम की मूल्य सूची मौजूद है।
• Customer Service के लिए कतारें, SLA और नॉलेज आलेख: वे कतारें जिनमें केस भेजे जाते हैं, सक्रिय SLA, और खोजने के लिए प्रकाशित आलेख।
• काम करने के लिए खुले रिकॉर्ड: लीड, अलग-अलग चरणों वाले अवसर और खुले केस।
• जहाँ बच सकें वहाँ कोई असली निजी डेटा नहीं। Everything वाली कॉपी में यह सब होता है, इसलिए जो टेस्टरों को देखने की ज़रूरत नहीं, उसे mask या anonymise करें।

सुरक्षा भूमिकाएँ, व्यवसाय इकाइयाँ और हर भूमिका के लिए यूज़र

UAT साबित करता है कि हर भूमिका अपना काम कर सकती है, और सिर्फ़ अपना काम। Dynamics 365 में यह यूज़र की सुरक्षा भूमिकाओं, व्यवसाय इकाई और टीमों पर निर्भर करता है। ऐप भी सुरक्षा भूमिकाओं के ज़रिए साझा किए जाते हैं: सही भूमिका के बिना यूज़र को ऐप दिखता तक नहीं।

• जिन भूमिकाओं को आप टेस्ट करते हैं उनकी सूची बनाएँ, जैसे सेल्स रिप्रेज़ेंटेटिव, सेल्स मैनेजर, सर्विस एजेंट और सर्विस सुपरवाइज़र, उनकी व्यवसाय इकाई के साथ।
• UAT परिवेश में हर टेस्टर को ठीक उसी भूमिका वाला एक यूज़र दें। हर यूज़र को लाइसेंस चाहिए, सैंडबॉक्स में भी।
• जब एक व्यक्ति कई भूमिकाएँ टेस्ट करे, तो हर भूमिका के लिए अलग टेस्ट यूज़र इस्तेमाल करें, या टेस्ट के बीच भूमिका बदलें और लिखें कि कौन-सी इस्तेमाल हुई।
• System Administrator भूमिका से कभी टेस्ट न करें। यह सब कुछ देखती है और सब कुछ कर सकती है, इसलिए यह ठीक वही समस्याएँ छिपा देती है जो UAT को ढूँढनी चाहिए।

टेस्टरों को परिवेश के बारे में क्या बताएँ

• UAT परिवेश का पता। सामान्य बुकमार्क प्रोडक्शन खोलता है।
• कौन-सा ऐप खोलना है, जैसे Sales Hub या Customer Service workspace, और किस अकाउंट से साइन इन करना है।
• कि डेटा टेस्ट डेटा है: वे जो भी करें वह किसी असली कस्टमर तक नहीं पहुँचता, और जो भी देखें वह मौजूदा नहीं है।
• साइन इन न कर पाने पर या ऐप न दिखने पर किसे कॉल करें।

UAT Studio मेंहर टेस्टर को एक Test role मिलता है, जैसे सुरक्षा भूमिका, और एक Test account, जो उनके टेस्ट के ऊपर Log in as … के रूप में दिखता है। Notes for testers में परिवेश का पता, टेस्ट मेलबॉक्स और किसे कॉल करना है, यह होता है। टेस्टर UAT Studio में ईमेल से आए कोड से, या Sign in with Microsoft से साइन इन करते हैं।

यूज़र स्टोरी और प्रक्रियाओं से टेस्ट केस

Dataverse की तालिकाओं से नहीं, बिज़नेस की प्रक्रियाओं से शुरू करें। दो प्रक्रियाएँ Dynamics 365 UAT के ज़्यादातर हिस्से को कवर करती हैं:

• लीड से अवसर से कोट तक। एक लीड आती है और qualify होकर एक अकाउंट, एक संपर्क और एक अवसर बनती है। अवसर व्यवसाय प्रक्रिया प्रवाह का पालन करता है, उसे मूल्य सूची से उत्पाद मिलते हैं, कोट बनता है, मंज़ूर और सक्रिय होता है, और डील जीती जाती है और अगली टीम या सिस्टम को जाती है।
• केस मैनेजमेंट। एक केस ईमेल से या पोर्टल के ज़रिए आता है, सही कतार या एजेंट तक भेजा जाता है, अपने SLA का पालन करता है, नॉलेज आलेख से हल होता है, ज़रूरत पड़ने पर escalate होता है, और resolve होता है।

हर प्रक्रिया को टेस्ट केस में बाँटें, हर एक में एक बिज़नेस परिदृश्य, जैसे मौजूदा अकाउंट के साथ लीड qualify करें। फिर जाँचें कि scope की हर यूज़र स्टोरी का कम से कम एक टेस्ट केस है।

व्यवसाय प्रक्रिया प्रवाह

व्यवसाय प्रक्रिया प्रवाह यूज़र को चरणों से होकर ले जाता है, ऐसे स्टेप के साथ जो अगले चरण से पहले ज़रूरी हो सकते हैं। इसे वैसे टेस्ट करें जैसे यूज़र करता है:

• हर चरण, और क्या होता है जब कोई ज़रूरी स्टेप खाली हो।
• हर शाखा, और हर भूमिका: कोई प्रवाह सिर्फ़ कुछ सुरक्षा भूमिकाओं के लिए चालू किया जा सकता है।

रूटिंग, SLA और नॉलेज

Customer Service में बहुत-सा काम बिना किसी क्लिक के होता है। टेस्ट करें कि सिस्टम को अपने-आप क्या करना चाहिए: ईमेल सही अकाउंट के लिए केस बनता है, केस सही कतार में पहुँचता है, SLA सही समय दिखाता है और खत्म होने से पहले चेतावनी देता है, और एजेंट को सही नॉलेज आलेख मिलता है।

ऐसे स्टेप जो बिज़नेस टेस्टर समझें

हर स्टेप को एक action और एक अपेक्षित नतीजे के रूप में, टेस्टर के शब्दों में लिखें। जहाँ ज़रूरी हो, टेस्ट डेटा जोड़ें। टेस्टर को कभी अंदाज़ा नहीं लगाना चाहिए कि कोई स्टेप पास हुआ या नहीं।

प्राथमिकता और जोखिम

हर टेस्ट केस बराबर ज़रूरी नहीं होता। हर एक को Must, Should या Could मार्क करें: Must वह है जिसे पहले दिन से काम करना ही है, जैसे कोट बनाना या केस रूट करना। जोखिम जोड़ें: गो-लाइव के बाद यह गलत हुआ तो उसकी क्या कीमत होगी। टेस्टर Must और ऊँचे जोखिम से शुरू करते हैं, ताकि समय कम पड़ने पर भी ज़रूरी टेस्ट हो जाएँ।

Unhappy paths भी जोड़ें: खाली छोड़ा गया ज़रूरी फ़ील्ड, सीमा से ज़्यादा डिस्काउंट, किसी दूसरी व्यवसाय इकाई का ऐसा यूज़र जिसे कोई रिकॉर्ड नहीं दिखना चाहिए।

UAT Studio मेंअपने टेस्ट केस Priority और Risk कॉलम के साथ Excel से इम्पोर्ट करें, उन्हें Azure DevOps Test Plans से पढ़ें, या टेम्पलेट लाइब्रेरी की Dynamics 365 स्क्रिप्ट से शुरू करें, जो हर पेड प्लान का ऐड-ऑन है। AI test design के साथ, AI आपकी Azure DevOps यूज़र स्टोरी से टेस्ट केस प्रस्तावित करता है, आपकी कंपनी के अपने मॉडल पर भी, जैसे Microsoft Foundry / Azure OpenAI। जब तक आप मंज़ूर न करें, कुछ भी टेस्ट केस नहीं बनता।

टेस्टर

ऐसे लोग चुनें जो हर दिन यह काम करते हैं: अकाउंट मैनेजर, सर्विस एजेंट, और मंज़ूरियों, कतारों और डैशबोर्ड के लिए उनके मैनेजर। Dynamics 365 इस्तेमाल करने वाली हर टीम और हर देश से टेस्टर लें, क्योंकि उनकी प्रक्रियाएँ, व्यवसाय इकाइयाँ और मूल्य सूचियाँ अलग होती हैं।

कितना समय

हर टेस्टर का समय उनके मैनेजर से तय करें, और रीटेस्ट के लिए समय रखें। जो टेस्टर साथ में कॉल ले रहे हैं या कस्टमर से मिलने जा रहे हैं, वे काम पूरा नहीं कर पाएँगे।

एक किक-ऑफ़

एक छोटे किक-ऑफ़ से शुरू करें: उनका टेस्ट क्यों ज़रूरी है, UAT परिवेश कैसे खोलें, नतीजा कैसे दर्ज करें और इश्यू कैसे लॉग करें। किक-ऑफ़ के दौरान हर टेस्टर से एक बार साइन इन करवाएँ और ऐप खुलवाएँ। लाइसेंस, भूमिकाओं और गलत परिवेश की ज़्यादातर समस्याएँ वहीं सामने आती हैं, टेस्ट डे पर नहीं।

एक टेस्ट डे या एक हफ़्ता

एक टेस्ट डे फ़ोकस और जल्दी जवाब देता है, और छोटे scope के लिए ठीक है। कुछ घंटों के ब्लॉक में बँटा एक हफ़्ता नए बिल्ड और रीटेस्ट के लिए जगह छोड़ता है, और कई प्रक्रियाओं वाले गो-लाइव के लिए ठीक है। दोनों में, ट्राइएज के लिए हर दिन एक समय तय करें।

UAT के दौरान

इश्यू दर्ज करना

अच्छा इश्यू बिना मीटिंग के फ़िक्स हो सकता है। टेस्टरों से माँगें:

• स्टेप, उन्हें क्या उम्मीद थी और उसके बजाय क्या हुआ।
• पेज का एक स्क्रीनशॉट, अगर कोई error message था तो उसके साथ।
• रिकॉर्ड का लिंक। यह ब्राउज़र के address bar में होता है और कंसल्टेंट को सीधे उस अवसर या केस पर ले जाता है जहाँ गड़बड़ हुई।
• वह यूज़र और सुरक्षा भूमिका जिससे उन्होंने टेस्ट किया।

UAT Studio मेंChrome और Edge के लिए ब्राउज़र एक्सटेंशन, Dynamics 365 के बगल में एक साइड पैनल में टेस्ट दिखाता है। फ़ेल हुआ स्टेप अपने साथ स्क्रीनशॉट, रिकॉर्ड का लिंक और पेज के error messages ले जाता है। इश्यू पर टेस्टर की भूमिका उनके नाम के बगल में दिखती है।

ट्राइएज

बिज़नेस और Dynamics 365 टीम के साथ मिलकर हर दिन नए इश्यू देखें। हर एक को गंभीरता और फ़िक्स करने वाला व्यक्ति दें, और तय करें:

• Fix: असली समस्या, इसी रिलीज़ में फ़िक्स।
• Reject: Dynamics 365 डिज़ाइन के अनुसार काम करता है, या टेस्ट गलत था।
• Change request: एक इच्छा, कोई defect नहीं। यह इस रिलीज़ में नहीं, बैकलॉग में जाता है।

फ़िक्स किए जाने वाले इश्यू डेवलपरों को भेजें, अक्सर Azure DevOps में, स्क्रीनशॉट और रिकॉर्ड लिंक के साथ।

रीटेस्ट

जब फ़िक्स UAT परिवेश में नए बिल्ड में आ जाता है, तो इश्यू पाने वाला टेस्टर उस स्टेप को फिर से टेस्ट करता है। लिखें कि हर रीटेस्ट किस बिल्ड पर हुआ। बड़े फ़िक्स के बाद उसके आसपास की प्रक्रियाओं को भी फिर से टेस्ट करें।

रोज़ाना स्टेटस

स्टीयरिंग कमेटी को हर दिन एक छोटा स्टेटस भेजें: योजना के मुकाबले प्रगति, गंभीरता के अनुसार खुले इश्यू, और क्या रुकावट है। go/no-go मीटिंग में कोई सरप्राइज़ नहीं।

UAT Studio मेंट्राइएज एक साझा स्क्रीन पर Fix, Reject और Change request के साथ चलता है। इश्यू Azure DevOps में एक Bug वर्क आइटम बन जाता है; वहाँ काम पूरा होने पर इश्यू Ready for retest हो जाता है और टेस्टर को ईमेल मिलता है। हर राउंड अपना रिलीज़, बिल्ड और परिवेश दर्ज रखता है। Microsoft Teams में एक चैनल को नए इश्यू, राउंड और साइन-ऑफ़ मिलते हैं।

साइन-ऑफ़ और go/no-go

UAT बिज़नेस के फ़ैसले से खत्म होता है। पहले टेस्ट डे से पहले exit criteria तय कर लें, ताकि अंत में उन पर कोई बहस न हो:

• कोई Critical इश्यू खुला नहीं है।
• हर Must टेस्ट केस पास हो चुका है।
• हर खुले High इश्यू के लिए एक वर्कअराउंड या फ़िक्स की एक तारीख़ है, जिसे बिज़नेस स्वीकार करता है।
• स्कोप के हर टेस्ट केस का एक नतीजा है।

कौन साइन करता है

हर प्रक्रिया का owner साइन-ऑफ़ करता है, जैसे लीड से कोट तक के लिए सेल्स डायरेक्टर और केस मैनेजमेंट के लिए कस्टमर सर्विस प्रमुख। वे चुनते हैं: स्वीकार, शर्तों के साथ स्वीकार, या अस्वीकार। हर शर्त लिखें, कौन करेगा और कब तक। फिर स्टीयरिंग कमेटी गो-लाइव पर फ़ैसला करती है।

रिपोर्ट में क्या जाता है

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

UAT Studio मेंहर ग्रुप का साइन-ऑफ़: Accepted, Accepted with conditions या Rejected। डिफ़ॉल्ट रूप से, कोई Critical इश्यू खुला रहते कोई स्वीकार नहीं कर सकता। आखिरी नतीजा आते ही go/no-go रिपोर्ट PDF या स्लाइड के रूप में तैयार होती है।

तय लय पर रिग्रेशन राउंड

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

• एक लय चुनें, जैसे हर महीने या हर तिमाही एक रिग्रेशन राउंड, और तारीख़ें अभी टेस्टरों के कैलेंडर में डाल दें।
• हर राउंड से पहले Microsoft roadmap और अपने एडमिन के लिए आए संदेश पढ़ें, और लिखें कि कौन-से बदलाव आपकी प्रक्रियाओं को छूते हैं।
• preview या early access वाले फ़ीचर पहले किसी सैंडबॉक्स परिवेश में आज़माएँ, उनके आपके यूज़र तक पहुँचने से पहले।
• बिज़नेस के कुछ टेस्टरों के साथ Must टेस्ट केस फिर से टेस्ट करें, और समय हो तो Should भी।
• UAT की तरह इश्यू लॉग करें, और बदलाव के आपके यूज़र तक पहुँचने से पहले उन्हें फ़िक्स करें।

UAT Studio मेंप्रोजेक्ट के CRM के रूप में Dynamics 365 चुनें। Start a regression round पिछले UAT से आपके चुने टेस्ट केस उनके स्टेप, टेस्ट डेटा और अपेक्षित नतीजों के साथ कॉपी करता है: Must and Should, Only Must या All test cases in scope।

इस्तेमाल के लिए मुफ़्त

UAT से पहले, दौरान और बाद में जो कुछ तय करना है, उसके लिए देखें CRM गो-लाइव के लिए UAT चेकलिस्ट, जो मुफ़्त Excel फ़ाइल के रूप में भी है। Dynamics 365 UAT के लिए UAT Studio क्या करता है, यह जानने के लिए देखें Dynamics 365 UAT।

Microsoft, Dynamics 365, Power Platform, Azure DevOps और Microsoft Teams, Microsoft समूह की कंपनियों के ट्रेडमार्क हैं। UAT Studio, Microsoft से संबद्ध या उसके द्वारा समर्थित नहीं है।