SAP यूज़र एक्सेप्टेंस टेस्टिंग: ज़िम्मेदार कौन और इसे कैसे चलाएँ

SAP यूज़र एक्सेप्टेंस टेस्टिंग (UAT) वह चरण है जिसमें बिज़नेस यूज़र कॉन्फ़िगर किए गए सिस्टम में अपनी प्रक्रियाएँ चलाते हैं और go-live से पहले उसे औपचारिक रूप से स्वीकार करते हैं। इसकी ज़िम्मेदारी बिज़नेस की है, IT और इम्प्लीमेंटेशन पार्टनर इसमें सहयोग करते हैं, और S/4HANA प्रोग्राम में मैं इसके लिए कम से कम 6 से 8 सप्ताह रखता हूँ।

टेस्टिंग की जो विफलता मैं सबसे ज़्यादा देखता हूँ, वह सीधी है: UAT और सिस्टम इंटीग्रेशन टेस्टिंग (SIT) में पर्याप्त टेस्टिंग न होना। जब टाइमलाइन खिसकती है, तो यही दो चरण दबते हैं, और कमियाँ go-live के बाद सामने आती हैं।

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

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

वजह नाम में ही है। स्वीकृति एक बिज़नेस फ़ैसला है कि सिस्टम बिज़नेस चलाता है या नहीं, इसलिए यह फ़ैसला केवल वही लोग दे सकते हैं जो बिज़नेस चलाते हैं। अगर IT या पार्टनर UAT पर साइन-ऑफ़ करता है, तो किसी ने कुछ भी स्वीकार नहीं किया।

SAP की अपनी मेथडोलॉजी भी यही कहती है। उसकी S/4HANA Cloud Private Edition के लिए टेस्ट स्ट्रैटेजी गाइडेंस UAT को Realize चरण में रखती है। पार्टनर के कॉन्फ़िगरेशन विशेषज्ञ मैनुअल टेस्ट केस तैयार करते हैं, और ग्राहक के लाइन-ऑफ़-बिज़नेस विशेषज्ञ उन्हें चलाते हैं और नतीजे दर्ज करते हैं।

काम का एक व्यावहारिक बँटवारा ऐसा दिखता है:

भूमिका	UAT में किसकी ज़िम्मेदारी	किसकी ज़िम्मेदारी नहीं
बिज़नेस प्रोसेस ओनर्स	परिदृश्यों का स्कोप, स्वीकृति के मानदंड, अपनी प्रक्रिया का अंतिम साइन-ऑफ़	कॉन्फ़िगरेशन या कोड ठीक करना
की-यूज़र और टेस्टर	स्क्रिप्ट चलाना, नतीजे और सबूत दर्ज करना, खोजें उठाना	अकेले यह तय करना कि कोई डिफ़ेक्ट “डिफ़ेक्ट नहीं” है
UAT लीड (बिज़नेस की ओर से)	रोज़ का प्लान, प्रगति, ट्राइएज की अध्यक्षता, स्पॉन्सर को तैयारी की रिपोर्ट	टेक्निकल सुधार
इम्प्लीमेंटेशन पार्टनर	स्क्रिप्ट का मसौदा, टेस्ट सिस्टम की तैयारी, डिफ़ेक्ट ठीक करना, दोबारा टेस्ट में सहयोग	स्वीकृति
आंतरिक IT	एनवायरनमेंट, एक्सेस, दूसरे सिस्टम से इंटरफ़ेस, ट्रांसपोर्ट	स्वीकृति
डेटा टीम	टेस्ट डेटा लोड और रिफ़्रेश करना, रिकंसिलिएशन में सहयोग	बिज़नेस परिदृश्य का डिज़ाइन

UAT लीड बिज़नेस से आना चाहिए, पार्टनर से नहीं। पार्टनर के नेतृत्व वाला UAT यह साबित करने की ओर खिसक जाता है कि बिल्ड काम करता है, और यह उस सवाल से अलग है कि बिज़नेस उस पर चल सकता है या नहीं।

UAT को कम से कम 6 से 8 सप्ताह चाहिए। इससे कम हो, तो बिज़नेस आसान रास्ता एक बार टेस्ट करता है, सुधारों को दोबारा टेस्ट करने का समय नहीं मिलता, और वह कभी उन अपवादों तक नहीं पहुँचता जहाँ असली समस्याएँ रहती हैं।

ये हफ़्ते तभी काम करते हैं जब UAT स्थिर सिस्टम पर शुरू हो। SAP की सलाह है कि बिज़नेस प्रक्रियाएँ तब टेस्ट की जाएँ जब इंटीग्रेशन सेट हो चुके हों और उस प्रक्रिया का डेटा माइग्रेट हो चुका हो। इसका मतलब है कि SIT पहले, तय एग्ज़िट क्राइटेरिया के सामने, पूरी होनी चाहिए, और मेरी S/4HANA टेस्टिंग स्ट्रैटेजी गाइड बताती है कि ये साइकिल आपस में कैसे जुड़ते हैं।

पहला टेस्टर लॉग ऑन करे, उससे पहले ये चीज़ें तैयार होनी चाहिए:

1. साइन-ऑफ़ हो चुके प्रोसेस डिज़ाइन। स्क्रिप्ट इन्हीं से लिखी जाती हैं, इसलिए बिना साइन वाले डिज़ाइन का मतलब है अनिश्चित स्क्रिप्ट।
2. एंट्री क्राइटेरिया पूरे और दर्ज। SIT पूरी, कोई खुला क्रिटिकल डिफ़ेक्ट नहीं, और नियंत्रित सुधारों को छोड़कर टेस्ट सिस्टम फ़्रीज़।
3. प्रोडक्शन जैसा दिखने वाला टेस्ट सिस्टम। कॉन्फ़िगरेशन, इंटरफ़ेस, रोल और ऑथराइज़ेशन वैसे ही जैसे go-live पर होंगे।
4. वास्तविक टेस्ट डेटा। मास्क किया हुआ, प्रोडक्शन स्तर का, टेस्टिंग शुरू होने से पहले लोड और रिकंसाइल किया हुआ। मेरी SAP टेस्ट डेटा मैनेजमेंट गाइड इसका तरीका बताती है।
5. रोज़ के काम से मुक्त किए गए टेस्टर। उनके नाम तय कीजिए, उनके मैनेजर्स के साथ उनके घंटे तय कीजिए, और इसे लिखित में रखिए।
6. नए सिस्टम पर प्रशिक्षित टेस्टर। जिन Fiori ऐप और ट्रांज़ैक्शन का वे इस्तेमाल करेंगे, उनका एक छोटा वॉकथ्रू, UAT से पहले, उसके दौरान नहीं।
7. एक टेस्ट मैनेजमेंट टूल। स्क्रिप्ट, नतीजे, सबूत और डिफ़ेक्ट एक ही जगह, समानांतर स्प्रेडशीट में नहीं।

आइटम 5 वह जगह है जहाँ UAT आम तौर पर चुपचाप विफल होता है। जिन टेस्टर से मंथ-एंड क्लोज़ के आसपास UAT फ़िट करने को कहा जाता है, वे मंथ-एंड को पहले रखेंगे, और वे सही होंगे।

UAT स्क्रिप्ट एक बिज़नेस परिदृश्य है, ट्रांज़ैक्शन की सूची नहीं। “एक सेल्स ऑर्डर बनाइए” एक स्क्रीन टेस्ट करता है। “क्रेडिट होल्ड पर रखे एक नए ग्राहक से ऑर्डर लीजिए, उसे रिलीज़ कीजिए, डिलीवर कीजिए और इनवॉइस कीजिए” बिज़नेस को टेस्ट करता है।

स्क्रिप्ट साइन-ऑफ़ हो चुके प्रोसेस डिज़ाइन से बनाइए, और हर एक को बिज़नेस की भाषा में एक साफ़ अपेक्षित नतीजा दीजिए। टेस्टर को किसी कंसल्टेंट से पूछे बिना पास या फ़ेल कह पाना चाहिए।

चार तरह के परिदृश्य कवर कीजिए:

1. मुख्य फ़्लो। वे रोज़ की प्रक्रियाएँ जो बिज़नेस को चलाती हैं, जैसे order to cash, procure to pay और record to report।
2. अपवाद। रिटर्न, क्रेडिट ब्लॉक, आंशिक डिलीवरी, कीमत में बदलाव, रिवर्सल और अस्वीकार होने वाली मंज़ूरियाँ।
3. पीरियड-एंड। मंथ-एंड और ईयर-एंड के वे चरण जो फ़ाइनेंस टीम असल में चलाती है, उसी क्रम में जिसमें वह चलाती है।
4. रोल की जाँच। हर टेस्टर उसी रोल में काम करे जो go-live पर उसके पास होगा, ताकि ऑथराइज़ेशन की कमियाँ अभी दिखें।

पार्टनर को स्क्रिप्ट का मसौदा बनाने दीजिए, फिर की-यूज़र से उन्हें अपनी भाषा में दोबारा लिखवाइए। अगर बिज़नेस बिना मदद के किसी स्क्रिप्ट को नहीं समझ पाता, तो वह बिल्ड टीम के लिए लिखी गई थी।

SAP Cloud ALM में मैनुअल टेस्ट केस एक प्रक्रिया से शुरू होते हैं, और टेस्ट प्लान उन्हें साइकिल में समूहित करते हैं। टेस्टर हर चरण को पास या फ़ेल करते हैं, असली नतीजा दर्ज करते हैं, और टेस्ट एक्ज़ीक्यूशन से ही डिफ़ेक्ट उठाते हैं, जिससे स्क्रिप्ट और डिफ़ेक्ट के बीच की कड़ी बनी रहती है।

जो प्रोग्राम अब भी टेस्ट मैनेजमेंट के लिए SAP Solution Manager 7.2 चला रहे हैं, वे ध्यान दें कि इसका मेनस्ट्रीम मेंटेनेंस 2027 के अंत में समाप्त होता है (SAP Support)। नए प्रोग्राम Cloud ALM पर प्लान कीजिए।

UAT की हर खोज डिफ़ेक्ट नहीं होती। सबको डिफ़ेक्ट मानने से पार्टनर दब जाता है, और सबको चेंज रिक्वेस्ट मानने से असली विफलताएँ छिप जाती हैं।

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

एक सरल वर्गीकरण ज़्यादातर खोजों को कवर करता है:

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

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

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

SAP की Activate ट्रेनिंग कहती है कि Realize चरण तब पूरा होता है जब यूज़र एक्सेप्टेंस टेस्टिंग पूरी और साइन-ऑफ़ हो जाए। उस साइन-ऑफ़ को एक दस्तावेज़ बनाइए, ईमेल का सिलसिला नहीं।

हर बिज़नेस प्रोसेस ओनर अपनी प्रक्रिया के लिए साइन करता है। साइन-ऑफ़ में यह दर्ज होना चाहिए:

1. क्या टेस्ट हुआ। चलाए गए, पास और फ़ेल हुए परिदृश्य, टेस्ट टूल में रखे सबूत के साथ।
2. क्या अभी खुला है। हर खुला डिफ़ेक्ट, उसकी सेवेरिटी, ज़िम्मेदार और लक्ष्य तारीख़ के साथ।
3. वर्कअराउंड के साथ क्या स्वीकार हुआ। हर एक का नाम, उस वर्कअराउंड के साथ जिसे चलाने पर बिज़नेस सहमत हुआ है।
4. किसने और कब साइन किया। हर प्रक्रिया के लिए एक नामित व्यक्ति, कोई कमेटी नहीं।

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

UAT साइन-ऑफ़ go-live का फ़ैसला नहीं है। यह उस फ़ैसले में एक इनपुट है।

go-live की जिस शर्त पर मैं ज़ोर देता हूँ, वह है पहले से तय एक विस्तृत कटओवर चेकलिस्ट। UAT साइन-ऑफ़ उसमें एक लाइन है, डेटा रिकंसिलिएशन, ट्रेनिंग और कटओवर रिहर्सल के साथ।

साइन-ऑफ़ के बाद जो स्वीकार हुआ है उसकी रक्षा कीजिए। यहाँ से go-live तक हर सुधार और ट्रांसपोर्ट को दोबारा टेस्टिंग चाहिए, और मेरी SAP रिग्रेशन टेस्टिंग गाइड बताती है कि इसे नियंत्रण में कैसे रखें।

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

एक सरल ढाँचा काफ़ी है:

सेक्शन	इसमें क्या होता है	ज़िम्मेदार
स्कोप	स्कोप की प्रक्रियाएँ, संगठनात्मक इकाइयाँ और रोल, और जो स्पष्ट रूप से बाहर है	बिज़नेस प्रोसेस ओनर्स
शेड्यूल	शुरू और ख़त्म होने की तारीख़ें, साइकिल, दोबारा टेस्ट की विंडो, पीरियड-एंड रन	UAT लीड
टीम	प्रक्रिया के हिसाब से टेस्टर, रोज़ के काम से उनकी मुक्ति, पार्टनर और IT सपोर्ट के संपर्क	UAT लीड और लाइन मैनेजर्स
एंट्री क्राइटेरिया	SIT एग्ज़िट पूरा, टेस्ट सिस्टम फ़्रीज़, डेटा लोड और रिकंसाइल, टेस्टर प्रशिक्षित	UAT लीड, प्रोग्राम मैनेजर के साथ
एनवायरनमेंट और डेटा	टेस्ट सिस्टम, स्कोप के इंटरफ़ेस, मास्क किया गया प्रोडक्शन-स्तर का डेटा, रिफ़्रेश प्लान	IT और डेटा टीम
स्क्रिप्ट	हर प्रक्रिया के परिदृश्यों की सूची, अपेक्षित नतीजे, प्रोसेस डिज़ाइन से कड़ी	पार्टनर मसौदा बनाता है, की-यूज़र मंज़ूर करते हैं
डिफ़ेक्ट प्रक्रिया	खोज के प्रकार, सेवेरिटी की परिभाषाएँ, रोज़ का ट्राइएज, दोबारा टेस्ट के नियम	UAT लीड ट्राइएज की अध्यक्षता करता है
रिपोर्टिंग	रोज़ की प्रगति, सेवेरिटी के हिसाब से खुले डिफ़ेक्ट, स्पॉन्सर तक रुकावटें	UAT लीड
एग्ज़िट क्राइटेरिया	सेवेरिटी के हिसाब से खुले डिफ़ेक्ट की सीमाएँ, पास हुए परिदृश्य, तय वर्कअराउंड	बिज़नेस प्रोसेस ओनर्स
साइन-ऑफ़	हर प्रोसेस ओनर का हस्ताक्षर ब्लॉक, स्वीकार किए गए वर्कअराउंड की सूची	बिज़नेस प्रोसेस ओनर्स और स्पॉन्सर

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

इसी महीने बिज़नेस से अपना UAT लीड तय कीजिए, और हर प्रोसेस ओनर से मुक्त समय वाले टेस्टर नामित करने को कहिए। फिर SIT के बाद UAT के लिए प्लान में 6 से 8 सप्ताह रखिए, और टाइमलाइन तंग होने पर उनका बचाव कीजिए।

अगर आपका UAT पार्टनर चला रहा है, या बार-बार दबाया जा रहा है, तो मैं प्रोग्राम को इसे ठीक से सेट करने में मदद करता हूँ। आप यहाँ मुझसे संपर्क कर सकते हैं।

SAP में यूज़र एक्सेप्टेंस टेस्टिंग क्या है?

यह वह चरण है जिसमें बिज़नेस यूज़र कॉन्फ़िगर किए गए SAP सिस्टम को अपनी असली प्रक्रियाओं के सामने टेस्ट करते हैं और go-live से पहले उसे औपचारिक रूप से स्वीकार करते हैं। SAP Activate में यह Realize चरण में, इंटीग्रेशन टेस्टिंग के बाद होता है। की-यूज़र परिदृश्य स्क्रिप्ट चलाते हैं, नतीजे दर्ज करते हैं और खोजें उठाते हैं, और प्रोसेस ओनर्स साइन-ऑफ़ करते हैं।

SAP प्रोजेक्ट में UAT की ज़िम्मेदारी किसकी है?

बिज़नेस की: प्रोसेस ओनर्स स्कोप तय करते हैं और साइन-ऑफ़ करते हैं, और की-यूज़र टेस्ट चलाते हैं। इम्प्लीमेंटेशन पार्टनर स्क्रिप्ट का मसौदा बनाता है और डिफ़ेक्ट ठीक करता है, और आंतरिक IT एनवायरनमेंट, एक्सेस और इंटरफ़ेस देता है। न IT को और न पार्टनर को बिज़नेस की ओर से सिस्टम स्वीकार करना चाहिए।

SAP UAT में कितना समय लगना चाहिए?

S/4HANA प्रोग्राम में कम से कम 6 से 8 सप्ताह की योजना बनाइए। इससे मुख्य फ़्लो, अपवाद और पीरियड-एंड चरण चलाने, फिर सुधारों को दोबारा टेस्ट करने का समय मिलता है। इससे छोटा UAT आम तौर पर आसान रास्ता एक बार टेस्ट करता है और बाकी सब go-live के बाद मिलता है।

SAP में SIT और UAT में क्या अंतर है?

सिस्टम इंटीग्रेशन टेस्टिंग (SIT) जाँचती है कि प्रक्रियाएँ और इंटरफ़ेस मॉड्यूल और सिस्टम के पार एक साथ काम करते हैं, और इसे मुख्य रूप से प्रोजेक्ट टीम चलाती है। UAT जाँचता है कि बिज़नेस सिस्टम पर अपनी प्रक्रियाएँ चला सकता है, और इसे बिज़नेस यूज़र चलाते हैं। UAT शुरू होने से पहले SIT पूरी हो जानी चाहिए।

UAT साइन-ऑफ़ में क्या शामिल होना चाहिए?

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

क्या UAT के लिए SAP Cloud ALM इस्तेमाल किया जा सकता है?

हाँ। SAP Cloud ALM प्रक्रियाओं से बने मैनुअल टेस्ट केस, हर साइकिल के लिए टेस्ट प्लान, चरण दर चरण पास या फ़ेल दर्ज करना और टेस्ट एक्ज़ीक्यूशन से डिफ़ेक्ट उठाना सपोर्ट करता है। SAP की सलाह के अनुसार पार्टनर के विशेषज्ञ टेस्ट केस तैयार करते हैं और ग्राहक के बिज़नेस विशेषज्ञ उन्हें चलाते हैं और नतीजे वहीं दर्ज करते हैं।