S/4HANA टेस्टिंग स्ट्रैटेजी: साइकिल, क्राइटेरिया और भूमिकाएँ

S/4HANA टेस्टिंग स्ट्रैटेजी तय करती है कि आप कौन से टेस्ट साइकिल चलाएँगे, किस क्रम में, हर एक का ज़िम्मेदार कौन होगा और कौन सा सबूत आपको एक से अगले पर जाने देगा। मेरे प्रोग्राम में इसमें राउंड में सिस्टम इंटीग्रेशन टेस्टिंग (SIT), राउंड में यूज़र एक्सेप्टेंस टेस्टिंग (UAT) और रिग्रेशन टेस्टिंग आती हैं, हर एक के लिखित एंट्री और एग्ज़िट क्राइटेरिया और एक नामित साइन-ऑफ़ के साथ।

जिन S/4HANA प्रोग्राम की मैं योजना बनाता हूँ, उनमें टेस्टिंग में लगभग 35 प्रतिशत प्रयास लगता है, इसलिए स्ट्रैटेजी पर उतनी ही सावधानी चाहिए जितनी बिल्ड प्लान पर।

टेस्टिंग के प्रकार मेरी SAP टेस्टिंग क्या है गाइड में कवर हैं। यह लेख स्ट्रैटेजी की परत है: साइकिल, क्राइटेरिया, भूमिकाएँ और दस्तावेज़ का ढाँचा।

SAP Activate ज़्यादातर टेस्टिंग Realize में रखता है। S/4HANA Cloud Private Edition के लिए SAP की अपनी टेस्ट स्ट्रैटेजी सामग्री यूनिट और स्ट्रिंग टेस्ट को अनौपचारिक मानती है। पूरी बिज़नेस प्रोसेस, इंटीग्रेशन, डेटा माइग्रेशन और यूज़र एक्सेप्टेंस टेस्ट औपचारिक हैं और उनका दस्तावेज़ बनाना ज़रूरी है।

S/4HANA प्रोग्राम में मैं यह क्रम प्लान करता हूँ:

S/4HANA टेस्ट साइकिल

1. 01

   यूनिट और स्ट्रिंग

   कंसल्टेंट बनाते समय हर कॉन्फ़िगर किया गया फ़ंक्शन और छोटी चेन टेस्ट करते हैं।

2. 02

   SIT राउंड

   मॉड्यूल, इंटरफ़ेस और माइग्रेट किए गए डेटा के पार पूरी प्रोसेस चेन।

3. 03

   UAT राउंड

   बिज़नेस यूज़र राउंड दर राउंड साबित करते हैं कि सिस्टम उनकी प्रक्रियाएँ चलाता है।

4. 04

   रिग्रेशन

   सुधारों, ट्रांसपोर्ट और रिलीज़ के बाद पहले से पास हुई चीज़ें दोबारा टेस्ट कीजिए।

5. 05

   मॉक कन्वर्ज़न और रिहर्सल

   कटओवर वैसे ही चलाइए जैसे वह असली रात को चलेगा, चेकलिस्ट के सामने।

6. 06

   Go-live

   तभी आगे बढ़िए जब तय कटओवर चेकलिस्ट पूरी हो जाए।

यूनिट और स्ट्रिंग टेस्टिंग

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

SAP की भाषा में अनौपचारिक, पर वैकल्पिक नहीं।

राउंड में सिस्टम इंटीग्रेशन टेस्टिंग

SIT मॉड्यूल, इंटरफ़ेस और कन्वर्ट या लोड किए गए डेटा के पार पूरी बिज़नेस प्रक्रियाएँ टेस्ट करती है। मैं इसे एक घटना के बजाय राउंड में प्लान करता हूँ, ताकि एक राउंड के बाद ठीक किए गए डिफ़ेक्ट अगले राउंड में दोबारा टेस्ट हों।

SIT राउंड की मेरी कोई तय संख्या नहीं है। संख्या स्कोप में आने वाली प्रक्रियाओं, इंटरफ़ेस और एंटिटी की संख्या पर निर्भर करती है, और स्ट्रैटेजी को बताना चाहिए कि कितने राउंड और क्यों।

राउंड में यूज़र एक्सेप्टेंस टेस्टिंग

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

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

रिग्रेशन टेस्टिंग

हर सुधार, ट्रांसपोर्ट और रिलीज़ उस चीज़ को तोड़ सकता है जो पहले पास हो चुकी है। रिग्रेशन टेस्टिंग हर बदलाव के बाद अहम प्रक्रियाओं को दोबारा चलाती है, प्रोग्राम के दौरान भी और go-live के बाद भी।

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

मॉक कन्वर्ज़न और कटओवर रिहर्सल

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

आख़िरी रिहर्सल असली रात की तरह चलना चाहिए: वही क्रम, वही लोग, वही चेकलिस्ट। मेरी S/4HANA माइग्रेशन टाइमलाइन और प्रोजेक्ट प्लान गाइड दिखाती है कि ये रन प्लान में कहाँ आते हैं।

ज़िम्मेदारी का सबसे अहम एक फ़ैसला: यूज़र एक्सेप्टेंस टेस्टिंग की ज़िम्मेदारी बिज़नेस की है। सिस्टम इंटीग्रेटर की नहीं और IT की भी नहीं।

इंटीग्रेटर स्क्रिप्ट तैयार कर सकता है और डिफ़ेक्ट ठीक कर सकता है। केवल वही लोग जो आपका फ़ाइनेंस क्लोज़, order-to-cash या प्लांट चलाते हैं, पुष्टि कर सकते हैं कि वे प्रक्रियाएँ काम करती हैं।

SAP की अपनी सलाह भी इसी ओर इशारा करती है। पार्टनर के कॉन्फ़िगरेशन विशेषज्ञ टेस्ट केस बनाते हैं, और ग्राहक के लाइन-ऑफ़-बिज़नेस विशेषज्ञ UAT चलाते हैं और नतीजे दर्ज करते हैं।

साइकिल के पार मैं ज़िम्मेदारी ऐसे बाँटूँगा:

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

स्ट्रैटेजी में भूमिकाएँ नहीं, नाम लिखिए। “फ़ाइनेंस प्रोसेस ओनर” एक भूमिका है; साइन करने पर सहमत एक नामित व्यक्ति ज़िम्मेदार है।

एंट्री क्राइटेरिया किसी साइकिल को तब शुरू होने से रोकते हैं जब वह सफल नहीं हो सकता। एग्ज़िट क्राइटेरिया उसे सिर्फ़ इसलिए ख़त्म होने से रोकते हैं कि कैलेंडर ऐसा कहता है।

दोनों Realize शुरू होने से पहले लिखिए, जब कोई डेडलाइन के दबाव में न हो। मेरी SAP क्वालिटी गेट्स गाइड बताती है कि ये क्राइटेरिया ऐसे औपचारिक गेट कैसे बनते हैं जिनका ज़िम्मेदार “अभी तैयार नहीं” कह सके।

नीचे की तालिका ढालने के लिए एक मार्गदर्शन है, नक़ल करने के लिए कोई स्टैंडर्ड नहीं। प्रतिशत और डिफ़ेक्ट की सीमाएँ अपने स्पॉन्सर के साथ तय कीजिए और स्ट्रैटेजी में दर्ज कीजिए:

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

दो नियम तालिका को काम का बनाते हैं। हर क्राइटेरियन का जवाब हाँ या ना में होता है, और हर एग्ज़िट का एक नामित हस्ताक्षरकर्ता होता है।

अगर कोई साइकिल अपने एग्ज़िट क्राइटेरिया से चूक जाए और बिज़नेस फिर भी आगे बढ़ना चाहे, तो इसे एक लिखित फ़ैसला बनाइए। उस व्यक्ति का नाम लिखिए जिसने जोखिम स्वीकार किया, और आगे ले जाए गए डिफ़ेक्ट भी।

टेस्ट मैनेजर इसे Prepare या शुरुआती Explore में लिखता है, और स्पॉन्सर इसे मंज़ूरी देता है। इसे इतना छोटा रखिए कि प्रोसेस ओनर्स इसे पढ़ें।

मैं ये सेक्शन देखने की उम्मीद करता हूँ:

1. स्कोप और उद्देश्य। कौन सी प्रक्रियाएँ, एंटिटी, इंटरफ़ेस और रिपोर्ट टेस्ट होंगी, और कौन सी स्पष्ट रूप से बाहर हैं।
2. टेस्ट के प्रकार और साइकिल। यूनिट, स्ट्रिंग, SIT राउंड, UAT राउंड, रिग्रेशन, परफ़ॉर्मेंस, डेटा माइग्रेशन टेस्टिंग और मॉक कन्वर्ज़न, राउंड की संख्या और उसके तर्क के साथ।
3. शेड्यूल और प्रयास। SAP Activate प्लान के भीतर हर साइकिल की तारीख़ें, UAT को कम से कम 6 से 8 सप्ताह के साथ, और लगभग 35 प्रतिशत टेस्टिंग हिस्से के सामने बजट किया गया प्रयास।
4. भूमिकाएँ और ज़िम्मेदारी। ऊपर वाली ज़िम्मेदारी की तालिका, नामों के साथ।
5. एंट्री और एग्ज़िट क्राइटेरिया। हर साइकिल के लिए एक सेट, हर एक के हस्ताक्षरकर्ता के साथ।
6. एनवायरनमेंट। किस साइकिल के लिए कौन से सिस्टम इस्तेमाल होंगे, उन्हें कैसे रिफ़्रेश किया जाएगा और प्रोजेक्ट के बदलावों को लाइव सपोर्ट के बदलावों से कैसे अलग रखा जाएगा।
7. टेस्ट डेटा। डेटा कहाँ से आता है, उसे कैसे मास्क किया जाता है और राउंड के बीच कैसे रिफ़्रेश किया जाता है। मेरी SAP टेस्ट डेटा मैनेजमेंट गाइड इसे गहराई से कवर करती है।
8. डिफ़ेक्ट मैनेजमेंट। सेवेरिटी की परिभाषाएँ, ट्राइएज की लय, प्राथमिकता कौन तय करता है और हर सेवेरिटी के लिए सुधार का लक्ष्य समय।
9. टूल। टेस्ट केस, नतीजे, डिफ़ेक्ट और साइन-ऑफ़ कहाँ रहते हैं, रिकॉर्ड के एक ही सिस्टम के साथ।
10. ऑटोमेशन का तरीका। कौन से टेस्ट ऑटोमेटेड हैं, कौन से मैनुअल रहते हैं और क्यों।
11. रिपोर्टिंग। साप्ताहिक टेस्ट रिपोर्ट क्या दिखाती है और उसे कौन पाता है।
12. कटओवर और go-live क्राइटेरिया। कटओवर चेकलिस्ट, उसे साबित करने वाले रिहर्सल और go या no-go का फ़ैसला कौन करता है।
13. जोखिम और धारणाएँ। टेस्टर की उपलब्धता, एनवायरनमेंट की तारीख़ें, डेटा की तैयारी और थर्ड पार्टी पर निर्भरताएँ।

टूल की बात करें तो नए प्रोग्राम के लिए SAP Cloud ALM डिफ़ॉल्ट है। SAP कहता है कि SAP Cloud ALM के लिए कोई अलग लाइसेंस नहीं है: यह Enterprise Support के साथ शामिल है, और इसके टेस्ट मैनेजमेंट ऐप औपचारिक टेस्ट केस, रन और नतीजे रखते हैं।

SAP Solution Manager 7.2 अब भी कई प्रोग्राम में इस्तेमाल होता है, पर इसका मेनस्ट्रीम मेंटेनेंस 2027 के अंत में समाप्त होता है। ऑटोमेशन के लिए SAP SAP Test Automation by Tricentis बेचता है, जो Cloud ALM के साथ काम करता है; मेरी SAP टेस्टिंग टूल की तुलना व्यापक विकल्पों को कवर करती है।

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

एक आम सिलसिला: बिल्ड देर से चलता है, go-live की तारीख़ तय रहती है, और हफ़्ते टेस्ट साइकिल से कटते हैं क्योंकि वे प्लान के अंत में होते हैं।

ये वे पैटर्न हैं जो ऐसा कराते हैं, और हर एक के बारे में क्या करें:

1. यूनिट टेस्टिंग पूरी होने से पहले SIT शुरू हो जाती है। पहला SIT राउंड यूनिट टेस्ट राउंड बन जाता है। एंट्री क्राइटेरिया पर टिके रहिए।
2. UAT दो या तीन हफ़्ते के लिए प्लान किया जाता है। बिज़नेस यूज़र उतने समय में रोज़ के काम के साथ ठीक से टेस्ट नहीं कर सकते। कम से कम 6 से 8 सप्ताह प्लान कीजिए और टेस्टर को मुक्त कीजिए।
3. इंटीग्रेटर बिज़नेस की जगह UAT चलाता है। स्क्रिप्ट पास हो जाती हैं, और बिज़नेस को कमियाँ go-live के बाद मिलती हैं। UAT की ज़िम्मेदारी प्रोसेस ओनर्स के पास रखिए।
4. टेस्टिंग को बजट में एक छोटी लाइन माना जाता है। लगभग 35 प्रतिशत प्रयास वाली टेस्टिंग का बजट अगर उसके एक अंश पर बना है, तो सबसे पहले वही कटती है।
5. एग्ज़िट क्राइटेरिया साइकिल के दौरान लिखे जाते हैं। वे आख़िर में वही बन जाते हैं जो टीम ने हासिल किया हो। उन्हें Realize से पहले लिखिए।
6. Go-live का फ़ैसला भरोसे पर होता है, चेकलिस्ट पर नहीं। कोई नहीं दिखा पाता कि क्या तय हुआ था, इसलिए कोई नहीं बता पाता कि क्या छूट रहा है।

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

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

Realize शुरू होने से पहले अपने टेस्ट मैनेजर से टेस्ट स्ट्रैटेजी दस्तावेज़ माँगिए और उसे ऊपर के ढाँचे से मिलाइए। अगर उसमें UAT का कोई नामित ज़िम्मेदार नहीं है, UAT को 6 से 8 सप्ताह से कम दिए गए हैं, या हर साइकिल के एंट्री और एग्ज़िट क्राइटेरिया नहीं हैं, तो पहले वह ठीक कीजिए।

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

S/4HANA टेस्टिंग स्ट्रैटेजी क्या है?

यह वह प्लान है जो तय करता है कि कौन से टेस्ट साइकिल चलेंगे, किस क्रम में, हर एक का ज़िम्मेदार और साइन-ऑफ़ करने वाला कौन है, और कौन सा सबूत प्रोग्राम को एक साइकिल से अगले पर जाने देता है। S/4HANA प्रोग्राम में इसमें आम तौर पर यूनिट और स्ट्रिंग टेस्टिंग, SIT राउंड, UAT राउंड, रिग्रेशन, डेटा माइग्रेशन टेस्टिंग और कटओवर रिहर्सल आते हैं।

S/4HANA प्रोग्राम का कितना हिस्सा टेस्टिंग होता है?

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

S/4HANA प्रोजेक्ट में UAT को कितना समय लेना चाहिए?

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

SAP में यूज़र एक्सेप्टेंस टेस्टिंग की ज़िम्मेदारी किसकी होनी चाहिए?

बिज़नेस की, नामित प्रोसेस ओनर्स के ज़रिए। सिस्टम इंटीग्रेटर स्क्रिप्ट तैयार कर सकता है, एनवायरनमेंट संभाल सकता है और डिफ़ेक्ट ठीक कर सकता है, पर केवल वही लोग जो प्रक्रियाएँ चलाते हैं, पुष्टि कर सकते हैं कि सिस्टम उनके लिए काम करता है।

SAP टेस्टिंग में एंट्री और एग्ज़िट क्राइटेरिया क्या होते हैं?

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

S/4HANA go-live चेकलिस्ट में क्या शामिल होना चाहिए?

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