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

Salesforce में UAT कब चाहिए

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

• गो-लाइव। पहला Sales Cloud या Service Cloud, या किसी दूसरे CRM से आना।
• नया क्लाउड या बड़ा बदलाव। Sales Cloud के साथ Service Cloud जोड़ना, CPQ, ERP के साथ नया इंटीग्रेशन, या case routing का नया तरीका।
• हर Salesforce रिलीज़। Salesforce की साल में तीन रिलीज़ होती हैं: Spring, Summer और Winter। Winter रिलीज़ पतझड़ में आती है और अगले साल का नंबर रखती है। हर रिलीज़ आपकी org के काम करने का तरीका बदल सकती है, भले ही आपने खुद कुछ न बदला हो।
• सैंडबॉक्स प्रीव्यू। preview instance पर मौजूद सैंडबॉक्स को नई रिलीज़ प्रोडक्शन से कुछ हफ़्ते पहले मिलती है। यही टेस्ट करने का आपका समय है। हर रिलीज़ से पहले Salesforce बताता है कि कौन-से instance प्रीव्यू में हैं और किसी सैंडबॉक्स को वहाँ रखने के लिए क्या करना है। इसे समय पर जाँचें, क्योंकि refresh किसी सैंडबॉक्स को प्रीव्यू में ला या उससे बाहर कर सकता है।

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

सैंडबॉक्स

प्रोडक्शन में कभी टेस्ट न करें। Salesforce में चार तरह के सैंडबॉक्स होते हैं। उनमें से दो UAT के लिए ठीक हैं।

Refresh की योजना बनाएँ

Refresh सैंडबॉक्स की हर चीज़ को प्रोडक्शन की नई कॉपी से बदल देता है। हर सैंडबॉक्स टाइप में दो refresh के बीच एक न्यूनतम समय होता है, और Full सैंडबॉक्स में यह सबसे लंबा होता है। इसलिए इसकी योजना बनाएँ:

• UAT से पहले refresh करें, उसके दौरान कभी नहीं। जाँचें कि सैंडबॉक्स अगली बार कब refresh हो सकता है।
• Refresh के बाद रिलीज़ को सैंडबॉक्स में deploy करें। जो काम सिर्फ़ सैंडबॉक्स में था, वह चला जाता है।
• Refresh के बाद के स्टेप करें: इंटीग्रेशन और named credentials को प्रोडक्शन नहीं, टेस्ट सिस्टम की ओर करें, और वे scheduled jobs बंद करें जिन्हें नहीं चलना चाहिए।
• Email deliverability जाँचें। नया या refresh किया गया सैंडबॉक्स सिर्फ़ सिस्टम ईमेल भेजता है। Web-to-lead जवाब, approvals और case ईमेल के लिए इससे ज़्यादा चाहिए, लेकिन Full सैंडबॉक्स में आपके contacts के असली ईमेल पते होते हैं। इसे खोलने से पहले टेस्ट पते इस्तेमाल करें।

टेस्ट डेटा

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

• हर तरह के कस्टमर के लिए accounts और contacts जिन्हें आप टेस्ट करते हैं, सही owner, region और record type के साथ।
• Products और price books। किसी product को दूसरी price book में आने से पहले standard price book में कीमत चाहिए। जाँचें कि हर सेल्स टीम की price books active हैं।
• काम करने के लिए खुले रिकॉर्ड: अलग-अलग stage वाली opportunities, खुले cases, और अगर आप entitlements टेस्ट करते हैं तो milestone के करीब वाले cases।
• जहाँ बच सकें वहाँ कोई असली निजी डेटा नहीं। Full सैंडबॉक्स सब कुछ कॉपी करता है, इसलिए जो टेस्टरों को देखने की ज़रूरत नहीं, उसे mask या anonymise करें।

हर profile और permission set के लिए यूज़र

UAT साबित करता है कि हर रोल अपना काम कर सकता है, और सिर्फ़ अपना काम। profile, role और permission sets के हर उस मेल के लिए एक टेस्ट यूज़र बनाएँ जिसे आप टेस्ट करते हैं, जैसे sales rep, sales manager और service agent। हर टेस्टर को अपना यूज़र मिलता है, ताकि दो लोग कभी एक साथ एक ही यूज़र में काम न करें।

Refresh के बाद Salesforce हर username में सैंडबॉक्स का नाम और हर यूज़र के ईमेल पते में .invalid जोड़ देता है। हर टेस्ट यूज़र का ईमेल ऐसे पते पर सेट करें जिसे टेस्टर पढ़ता है, वरना password reset और approval ईमेल कहीं नहीं पहुँचते।

Log in as से एडमिन Salesforce को किसी दूसरे यूज़र की नज़र से देख सकता है। टेस्टर की बताई समस्या देखने का यह अच्छा तरीका है। टेस्ट के लिए टेस्टर अपना ही टेस्ट यूज़र इस्तेमाल करते हैं: इसी से पता चलता है कि profile और permission sets सही हैं।

टेस्टरों को सैंडबॉक्स के बारे में क्या बताएँ

• सैंडबॉक्स का पता। इसमें सैंडबॉक्स का नाम होता है, या वे test.salesforce.com से साइन इन करते हैं। Salesforce का सामान्य लॉगिन पेज प्रोडक्शन खोलता है।
• उनका username, जो सैंडबॉक्स के नाम पर खत्म होता है, और उन्हें password कैसे मिलता है।
• कि डेटा टेस्ट डेटा है: वे जो भी करें वह किसी असली कस्टमर तक नहीं पहुँचता, और जो भी देखें वह मौजूदा नहीं है।
• साइन इन न कर पाने पर किसे कॉल करें, इससे पहले कि उनकी पूरी सुबह बर्बाद हो।

UAT Studio मेंहर टेस्टर को एक Test role और एक Test account मिलता है, जो उनके टेस्ट के ऊपर Log in as … के रूप में दिखता है। Notes for testers में सैंडबॉक्स का पता, टेस्ट मेलबॉक्स और किसे कॉल करना है, यह होता है।

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

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

• Lead to cash। एक lead web-to-lead से आता है, assign और convert होता है। Opportunity को price book से products मिलते हैं, quote बनता और approve होता है, deal जीती जाती है, और order या contract अगली टीम या सिस्टम को जाता है।
• Case management। एक case email-to-case या पोर्टल से आता है, सही queue या agent तक route होता है, अपने entitlement और milestones का पालन करता है, knowledge article से हल होता है, ज़रूरत पड़ने पर escalate होता है, और बंद होता है।

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

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

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

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

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

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

UAT Studio मेंअपने टेस्ट केस Priority और Risk कॉलम के साथ Excel से इम्पोर्ट करें, या टेम्पलेट लाइब्रेरी की Salesforce स्क्रिप्ट से शुरू करें, जो हर पेड प्लान का ऐड-ऑन है। टेस्टरों को अपने Must टेस्ट केस सबसे पहले दिखते हैं।

टेस्टर

ऐसे लोग चुनें जो हर दिन यह काम करते हैं: sales reps, service agents, और approvals, forecasts और reports के लिए उनके मैनेजर। Salesforce इस्तेमाल करने वाली हर टीम और हर देश से टेस्टर लें, क्योंकि उनकी प्रक्रियाएँ और price books अलग होती हैं।

कितना समय

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

एक किक-ऑफ़

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

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

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

दोनों में, ट्राइएज के लिए हर दिन एक समय तय करें।

UAT के दौरान

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

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

• स्टेप, उन्हें क्या उम्मीद थी और उसके बजाय क्या हुआ।
• पेज का एक स्क्रीनशॉट।
• रिकॉर्ड का लिंक। यह ब्राउज़र के address bar में होता है और डेवलपर को सीधे उस opportunity या case पर ले जाता है जहाँ गड़बड़ हुई।
• वह यूज़र जिससे उन्होंने टेस्ट किया, ताकि टीम जाने कि कौन-सा profile और permission sets इस्तेमाल हुए।

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

ट्राइएज

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

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

रीटेस्ट

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

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

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

UAT Studio मेंट्राइएज एक साझा स्क्रीन पर Fix, Reject और Change request के साथ चलता है। Ready for retest रीटेस्टर को ईमेल भेजता है। ईमेल से, या Microsoft Teams में, एक रोज़ाना ओवरव्यू पिछले दिन के नतीजे और इश्यू दिखाता है।

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

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

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

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

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

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

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

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

हर Salesforce रिलीज़ के लिए एक रिग्रेशन राउंड

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

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

UAT Studio मेंप्रोजेक्ट के CRM के रूप में Salesforce चुनें। फिर प्रोजेक्ट पेज आने वाली Salesforce रिलीज़ दिखाता है, सैंडबॉक्स प्रीव्यू की तारीख, प्रोडक्शन की तारीख और release notes के साथ। Start a regression round आपके चुने टेस्ट केस कॉपी करता है: Must and Should, Only Must या All test cases in scope।

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

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

Salesforce, Sales Cloud और Service Cloud, Salesforce, Inc. के ट्रेडमार्क हैं। UAT Studio, Salesforce से संबद्ध या उसके द्वारा समर्थित नहीं है।