CRM को रिग्रेशन टेस्टिंग की ज़रूरत क्यों है
गो-लाइव के बाद आपका CRM बदलता रहता है, तब भी जब आपकी अपनी टीम कुछ नहीं बदलती। Salesforce और Microsoft हर ग्राहक के लिए प्लेटफ़ॉर्म अपडेट करते हैं। ज़्यादातर बदलाव सुधार होते हैं। कुछ किसी पेज, किसी डिफ़ॉल्ट सेटिंग या किसी फ़ीचर के काम करने का तरीका बदल देते हैं, और कभी-कभार कोई बदलाव ऐसी चीज़ तोड़ देता है जिस पर आपका बिज़नेस निर्भर है।
रिग्रेशन टेस्ट एक सवाल का जवाब देता है: जो बिज़नेस ने गो-लाइव पर स्वीकार किया, क्या वह अब भी काम करता है? यह नया UAT नहीं है। यह सबसे ज़रूरी प्रक्रियाओं की एक छोटी, केंद्रित जाँच है, जो बदलाव के आपके यूज़र तक पहुँचने से पहले, काम जानने वाले लोग करते हैं।
आपकी अपनी रिलीज़ को भी यही जाँच चाहिए। एक नया इंटीग्रेशन, कोट पर एक नया फ़ील्ड, केस की रूटिंग में बदलाव: हर एक किसी ऐसी चीज़ को छू सकता है जो पहले काम करती थी।
Salesforce: साल में तीन रिलीज़
Salesforce की साल में तीन बड़ी रिलीज़ होती हैं: Spring, Summer और Winter। Winter रिलीज़ पतझड़ में आती है और अगले साल का नंबर रखती है। हर org अपग्रेड होता है, उन तारीख़ों पर जिन्हें Salesforce पहले से प्रकाशित करता है।
- सैंडबॉक्स प्रीव्यू। preview instance पर मौजूद सैंडबॉक्स को नई रिलीज़ प्रोडक्शन से कुछ हफ़्ते पहले मिलती है। यही आपकी टेस्ट करने की खिड़की है। हर रिलीज़ से पहले, Salesforce बताता है कि कौन-से instance प्रीव्यू में हैं और किसी सैंडबॉक्स को वहाँ रखने के लिए क्या करना है। एक refresh किसी सैंडबॉक्स को प्रीव्यू में ला सकता है या उससे बाहर कर सकता है, इसलिए समय रहते जाँच लें।
- Release notes। उन क्लाउड और फ़ीचर के लिए इन्हें पढ़ें जिन्हें आप इस्तेमाल करते हैं। देखें कि आपके लिए अपने-आप क्या चालू होता है, और क्या उन पेजों का रूप बदलता है जिनमें आपके यूज़र काम करते हैं।
- Release updates। कुछ बदलाव Setup में एक तारीख़ के साथ घोषित होते हैं, जिस दिन वे लागू कर दिए जाते हैं। उस तारीख़ से पहले उन्हें सैंडबॉक्स में टेस्ट करें, ताकि वे प्रोडक्शन में आपको चौंकाएँ नहीं।
इसलिए Salesforce के लिए लय तय है: हर रिलीज़ की प्रीव्यू खिड़की में एक रिग्रेशन राउंड, साल में तीन बार।
UAT Studio मेंप्रोजेक्ट के CRM के रूप में Salesforce चुनें। किसी रिलीज़ से लगभग दो महीने पहले से, प्रोजेक्ट पेज Coming CRM releases दिखाता है, सैंडबॉक्स प्रीव्यू की तारीख़, प्रोडक्शन की तारीख़ और release notes के लिंक के साथ। Salesforce ये तारीख़ें अब भी बदल सकता है, इसलिए release notes जाँचें।
Dynamics 365: पूरे साल अपडेट
Microsoft अब Dynamics 365 के बदलावों को साल में दो release waves में नहीं बाँधता। नए फ़ीचर और बदलाव पूरे साल आते रहते हैं। release plans अक्टूबर 2026 में आर्काइव कर दिए गए; जो आने वाला है, वह अब aka.ms/AIatWorkRoadmap पर Microsoft roadmap में है।
इसका मतलब है कि अब साल में ऐसा एक बड़ा पल नहीं है जिसके इर्द-गिर्द टेस्टिंग प्लान की जाए। बदलाव छोटे क़दमों में, ज़्यादा बार आते हैं। किसी बड़ी रिलीज़ का इंतज़ार अब काम नहीं करता, और हर एक बदलाव के बाद टेस्ट करना बहुत ज़्यादा है।
एक तय लय चुनें
जवाब है तय लय पर एक रिग्रेशन राउंड, बीच में Microsoft चाहे जो भी रिलीज़ करे:
- हर महीने जब CRM बिज़नेस के केंद्र में हो, आप कई ऐप और फ़ीचर इस्तेमाल करते हों, या अक्सर नए फ़ीचर चालू करते हों।
- हर तिमाही ऐसे स्थिर सेटअप के लिए जिसमें आपके अपने बदलाव कम हों।
- एक अतिरिक्त राउंड आपके अपने किसी बदलाव के गो-लाइव से पहले, या जब Microsoft का कोई बदलाव साफ़ तौर पर आपकी किसी मुख्य प्रक्रिया को छूता हो।
पूरे साल की तारीख़ें टेस्टरों के कैलेंडर में डाल दें। तय लय को निभाना उस राउंड से आसान है जो हर बार कुछ आने पर प्लान किया जाता है।
हर राउंड से पहले
- Microsoft roadmap और Microsoft 365 admin center में आपके एडमिन के लिए मैसेज पढ़ें, और नोट करें कि कौन-से बदलाव आपकी प्रक्रियाओं को छूते हैं।
- preview वाले फ़ीचर पहले किसी सैंडबॉक्स परिवेश में आज़माएँ, उनके आपके यूज़र तक पहुँचने से पहले।
- पक्का करें कि जिस सैंडबॉक्स में आप टेस्ट करते हैं, उसमें प्रोडक्शन जैसा ही वर्ज़न और वही समाधान हों।
UAT Studio मेंप्रोजेक्ट के CRM के रूप में Dynamics 365 चुनें, और हर राउंड Start a regression round से शुरू करें, अपने गो-लाइव के प्रोजेक्ट या अपने पिछले राउंड से।
UAT Studio मेंSetup में Check the Dynamics 365 updates पर Every quarter या Every month चुनें। तब प्रोजेक्ट पेज मौजूदा अवधि को रोडमैप के लिंक के साथ दिखाता है, और एडमिन को हर अवधि में एक ईमेल मिलता है, उसके शुरू होने से दो हफ़्ते पहले।
क्या दोबारा टेस्ट करें, यह चुनना
रिग्रेशन राउंड सब कुछ दोबारा टेस्ट करने की जगह नहीं है। इस क्रम में चुनें:
- Must टेस्ट केस। जिसे हर दिन काम करना ज़रूरी है: कोट बनाना, लीड कन्वर्ट करना, केस रूट करना, मंज़ूरियाँ। इन्हें हर राउंड में टेस्ट करें।
- जिसे बदलाव छूता है। release notes या roadmap को अपनी प्रक्रियाओं की सूची के साथ रखकर पढ़ें। कोट में बदलाव का मतलब है कोट के टेस्ट केस, Should और Could वाले भी।
- इंटीग्रेशन और ऑटोमेशन। ERP, वेबसाइट या ईमेल से जुड़ाव, और बैकग्राउंड में चलने वाले flows। ये चुपचाप टूटते हैं, इसलिए इन्हें जानबूझकर टेस्ट करें।
- Should टेस्ट केस, जब समय हो।
फिर देखें कि पिछले राउंड के बाद आपकी अपनी टीम ने क्या बदला। आपने ख़ुद जो कुछ बनाया और जिसे किसी ने प्लेटफ़ॉर्म के बदलाव के साथ टेस्ट नहीं किया, वह भी राउंड में शामिल है।
जो ज़रूरी है उसकी एक छोटी सूची रखें
एक बार लिख लें कि वे दस से बीस प्रक्रियाएँ कौन-सी हैं जिनके बिना बिज़नेस एक दिन भी नहीं चल सकता। वही हर रिग्रेशन राउंड का केंद्र हैं। हर छह महीने में प्रक्रिया-मालिकों के साथ, और अपने हर बड़े बदलाव के बाद, सूची की समीक्षा करें।
UAT Studio मेंRelease readiness ऐड-ऑन के साथ, Review the release दिखाता है कि कोई Salesforce रिलीज़ या Dynamics 365 अपडेट आपके किन टेस्ट केस को प्रभावित करता है, कारण सहित, जो अभी कवर नहीं है उसके लिए टेस्ट केस सुझाता है, और ज़रूरी अपडेट उनकी तारीख़ों के साथ सूचीबद्ध करता है। तब रिग्रेशन राउंड में ठीक Must टेस्ट केस, वे प्रभावित टेस्ट केस जो आप रखते हैं और नए जिन्हें आप मंज़ूर करते हैं, आते हैं। राउंड में Fail बताता है कि वह किस बदलाव के साथ आया। €99 प्रति माह: इसे Plan & billing में जोड़ें।
अपने टेस्ट केस दोबारा इस्तेमाल करें
आपके पास सबसे अच्छा रिग्रेशन टेस्ट आपके गो-लाइव UAT के टेस्ट केस हैं। वे ठीक वही बताते हैं जो बिज़नेस ने स्वीकार किया, स्टेप, टेस्ट डेटा और अपेक्षित नतीजों के साथ। हर राउंड के लिए नए न लिखें।
- गो-लाइव के बाद टेस्ट केस एक जगह, उनकी प्राथमिकता के साथ, सँभालकर रखें।
- जब आपकी अपनी प्रक्रिया बदले, तो उन्हें अपडेट करें, ताकि अगला राउंड CRM को वैसे टेस्ट करे जैसा वह अब है, न कि जैसा वह गो-लाइव पर था।
- हर राउंड से पहले टेस्ट डेटा जाँचें। सैंडबॉक्स refresh या प्रोडक्शन की कॉपी उन रिकॉर्ड को हटा या बदल सकती है जिन्हें टेस्ट केस इस्तेमाल करते हैं।
- प्रोडक्शन में मिले हर गंभीर इश्यू के लिए एक टेस्ट केस जोड़ें, ताकि अगली बार वह पकड़ा जाए।
ऐसे टेस्ट केस जिन्हें बिज़नेस टेस्टर फ़ॉलो कर सकें, यहाँ मेहनत के लायक हैं: वे बार-बार दोबारा इस्तेमाल होते हैं। देखें ऐसे टेस्ट केस लिखना जो बिज़नेस टेस्टर समझें।
UAT Studio मेंStart a regression round उस प्रोजेक्ट के टेस्ट केस कॉपी करता है जिससे आप शुरू करते हैं, उनके स्टेप, टेस्ट डेटा और अपेक्षित नतीजों के साथ। चुनें कि कौन-से साथ आएँ: Must and Should, Only Must या All test cases in scope; बिना प्राथमिकता वाला टेस्ट केस Should गिना जाता है। नए प्रोजेक्ट को ग्रुप और सेटिंग मिलती हैं, और आप Setup में टेस्टरों को आमंत्रित करते हैं। कुछ भी गढ़ा या बदला नहीं जाता।
कौन टेस्ट करे, और कितनी देर
कौन
रिग्रेशन राउंड को UAT से कम लोगों की ज़रूरत होती है, लेकिन वे फिर भी बिज़नेस से होने चाहिए। हर प्रक्रिया के लिए एक या दो की-यूज़र से कहें: ऐसे लोग जो हर दिन यह काम करते हैं और कुछ गड़बड़ होने पर तुरंत पहचान लेते हैं। CRM एडमिन राउंड तैयार करता है और बैकग्राउंड में चलने वाली चीज़ें टेस्ट करता है, लेकिन उसे अकेला टेस्टर नहीं होना चाहिए।
हर राउंड में उन्हीं लोगों से टेस्ट करवाएँ। वे तेज़ होते जाते हैं, और ऐसे छोटे बदलाव पकड़ लेते हैं जो किसी नए टेस्टर से छूट जाते।
कितने समय के लिए
- तैयारी: बदलाव पढ़ने, टेस्ट केस चुनने और टेस्ट डेटा जाँचने के लिए एक-दो दिन।
- टेस्टिंग: हर टेस्टर के लिए कुछ घंटे, मासिक राउंड में एक या दो दिनों में फैले, और बहुत बदलावों वाली Salesforce रिलीज़ के लिए एक हफ़्ते तक।
- फ़िक्स और रीटेस्ट: बदलाव के प्रोडक्शन तक पहुँचने से पहले, मिले इश्यू के लिए कुछ दिन रखें।
Salesforce के लिए, यह प्रीव्यू खिड़की में फ़िट होना चाहिए। खिड़की की शुरुआत में ही शुरू करें, आख़िरी हफ़्ते में नहीं।
जो मिले उसे दर्ज करना
इश्यू वैसे ही दर्ज करें जैसे UAT में: स्टेप, आपने क्या उम्मीद की थी, उसके बजाय क्या हुआ, एक स्क्रीनशॉट और रिकॉर्ड का लिंक। CRM टीम के साथ हर दिन उनका ट्राइएज करें। प्लेटफ़ॉर्म की वजह से हुए इश्यू के लिए पहले release notes या roadmap देखें: अक्सर यह एक ज्ञात बदलाव होता है, जिसके लिए कोई सेटिंग बदलनी होती है।
UAT Studio मेंहर राउंड अपनी रिलीज़, बिल्ड और परिवेश सँभालकर रखता है, ताकि go/no-go रिपोर्ट बताए कि क्या टेस्ट हुआ। फ़िक्स के बाद, डैशबोर्ड पर Failed and blocked only के साथ Start round 2 सिर्फ़ वही दोबारा टेस्ट करता है जो गलत हुआ; पिछले राउंड के नतीजे रखे जाते हैं।
प्रोडक्शन से पहले साइन-ऑफ़
रिग्रेशन राउंड UAT की तरह ही एक फ़ैसले के साथ ख़त्म होता है, बस छोटा। एग्ज़िट क्राइटेरिया एक बार तय करें, और हर राउंड में उन्हें इस्तेमाल करें:
- हर Must टेस्ट केस पास हो चुका है।
- कोई Critical इश्यू खुला नहीं है।
- हर खुले High इश्यू के लिए ऐसा वर्कअराउंड है जिसे बिज़नेस स्वीकार करता है, या बदलाव के प्रोडक्शन तक पहुँचने से पहले एक फ़िक्स।
हर प्रक्रिया का मालिक अपने हिस्से के लिए साइन ऑफ़ करता है: स्वीकृत, शर्तों के साथ स्वीकृत, या अस्वीकृत। Salesforce रिलीज़ में आप अपग्रेड रोक नहीं सकते, इसलिए अस्वीकृति का मतलब है प्रोडक्शन की तारीख़ से पहले एक फ़िक्स या वर्कअराउंड, और यूज़र को एक मैसेज। आपके अपने बदलाव के लिए, अस्वीकृति का मतलब है कि वह इंतज़ार करता है।
हर राउंड का नतीजा सँभालकर रखें। एक साल बाद आपके पास साफ़ रिकॉर्ड होता है कि हर बदलाव के बाद क्या टेस्ट हुआ, और उसे किसने स्वीकार किया। फ़ैसला कैसे तैयार करें, इसके लिए देखें go/no-go फ़ैसला।
UAT Studio मेंरिग्रेशन राउंड अपना एक अलग प्रोजेक्ट है, जिसकी Release वही रिलीज़ होती है, ताकि उसकी go/no-go रिपोर्ट बताए कि वह किस CRM रिलीज़ के बारे में है। प्रक्रिया-मालिक हर ग्रुप के लिए साइन ऑफ़ करते हैं, और साइन-ऑफ़ उसी राउंड का होता है।
इस्तेमाल के लिए मुफ़्त
CRM गो-लाइव के लिए UAT चेकलिस्ट रिग्रेशन राउंड के लिए भी काम करती है, मुफ़्त Excel फ़ाइल के रूप में। हर प्लेटफ़ॉर्म के लिए देखें Salesforce UAT और Dynamics 365 UAT।
Salesforce, Salesforce, Inc. का ट्रेडमार्क है। Microsoft और Dynamics 365, Microsoft समूह की कंपनियों के ट्रेडमार्क हैं। UAT Studio, Salesforce या Microsoft से संबद्ध नहीं है और उनके द्वारा समर्थित नहीं है।