SAP टेस्टिंग क्या है: प्रकार, चरण और ज़िम्मेदार कौन

SAP टेस्टिंग वह काम है जिससे साबित होता है कि कॉन्फ़िगर किया गया SAP सिस्टम आपकी बिज़नेस प्रक्रियाएँ आपके डेटा और आपके वॉल्यूम पर सही चलाता है, go-live से पहले भी और उसके बाद हर बदलाव पर भी। S/4HANA प्रोग्राम में इसमें छह तरह के टेस्ट आते हैं: यूनिट, सिस्टम इंटीग्रेशन (SIT), यूज़र एक्सेप्टेंस (UAT), रिग्रेशन, परफ़ॉर्मेंस और कटओवर रिहर्सल।

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

यह पेज पूरा परिचय है। हर प्रकार की अपनी अलग गाइड है, जिसका लिंक नीचे के सेक्शन में दिया गया है।

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

इसीलिए SAP टेस्टिंग स्क्रीन के इर्द-गिर्द नहीं, बिज़नेस प्रक्रियाओं के इर्द-गिर्द बनाई जाती है। Order to cash, procure to pay और record to report कई मॉड्यूल से होकर गुज़रती हैं, और जो टेस्ट एक ट्रांज़ैक्शन पर रुक जाता है, वह बहुत कम साबित करता है।

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

S/4HANA प्रोग्राम में मैं इन्हीं छह प्रकारों की योजना बनाता हूँ। तालिका बताती है कि हर एक क्या साबित करता है, कब चलता है और उसकी ज़िम्मेदारी किसकी होनी चाहिए।

टेस्टिंग का प्रकार	यह क्या साबित करता है	SAP Activate में कहाँ आता है	ज़िम्मेदार कौन
यूनिट टेस्टिंग	हर कॉन्फ़िगरेशन आइटम, प्रोग्राम या एन्हांसमेंट अपने आप में काम करता है	Realize, हर बिल्ड स्प्रिंट के भीतर	फ़ंक्शनल और टेक्निकल कंसल्टेंट
सिस्टम इंटीग्रेशन टेस्टिंग (SIT)	पूरी प्रक्रियाएँ वास्तविक डेटा के साथ मॉड्यूल और इंटरफ़ेस के पार चलती हैं	Realize, बिल्ड स्थिर होने के बाद राउंड में	प्रोग्राम टेस्ट लीड, प्रोसेस ओनर्स के साथ
यूज़र एक्सेप्टेंस टेस्टिंग (UAT)	बिज़नेस सिस्टम पर अपने असली परिदृश्य चला सकता है	Realize का अंतिम हिस्सा, Deploy से पहले	बिज़नेस
रिग्रेशन टेस्टिंग	जो पहले काम करता था, वह बदलाव के बाद भी काम करता है	Realize से आगे, फिर Run में हर रिलीज़ पर	टेस्ट लीड, जहाँ वॉल्यूम उचित ठहराए वहाँ ऑटोमेशन के साथ
परफ़ॉर्मेंस टेस्टिंग	सिस्टम एक साथ कई यूज़र्स और प्रोडक्शन वॉल्यूम को संभाल लेता है	Realize, go-live से पहले पूरी	प्रोग्राम-स्तर का परफ़ॉर्मेंस लीड, Basis के साथ
कटओवर रिहर्सल	go-live का क्रम, डेटा लोड और समय-सीमाएँ शुरू से अंत तक काम करती हैं	Deploy	कटओवर मैनेजर

SAP Activate में SAP टेस्टिंग

1. 01

   Prepare

   टेस्ट टूल, टीम और टेस्ट लैंडस्केप तैयार कीजिए।

2. 02

   Explore

   fit-to-standard के फ़ैसलों के साथ ही टेस्ट स्ट्रैटेजी लिखिए, ताकि हर ज़रूरत टेस्ट की जा सके।

3. 03

   Realize

   स्प्रिंट में यूनिट टेस्ट, फिर बिल्ड स्थिर होने पर SIT राउंड, परफ़ॉर्मेंस टेस्टिंग और UAT।

4. 04

   Deploy

   तय चेकलिस्ट के सामने कटओवर रिहर्सल, फिर go-live का फ़ैसला।

5. 05

   Run

   हर सपोर्ट बदलाव, अपग्रेड और रिलीज़ के लिए रिग्रेशन टेस्टिंग।

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

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

यह ज़रूरी है, पर काफ़ी नहीं। साफ़ यूनिट टेस्ट आपको यह नहीं बताता कि जब वह आइटम बाकी प्रक्रिया से मिलेगा तब क्या होगा।

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

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

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

यूज़र एक्सेप्टेंस टेस्टिंग

UAT में बिज़नेस पुष्टि करता है कि सिस्टम उस तरीके को सपोर्ट करता है जिससे वह go-live के बाद काम करेगा। यह बिज़नेस की ज़िम्मेदारी है, सिस्टम इंटीग्रेटर की नहीं, क्योंकि सिस्टम को स्वीकार केवल बिज़नेस ही कर सकता है।

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

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

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

मेरा तरीका है दो अलग लैंडस्केप चलाना, एक प्रोजेक्ट के लिए और एक बिज़नेस ऐज़ यूज़ुअल (BAU) के लिए। तब लाइव सपोर्ट के बदलाव और प्रोजेक्ट के बदलाव अलग-अलग टेस्ट होते हैं, और कोई भी दूसरे में छिपे डिफ़ेक्ट को ढकता नहीं। मेरी SAP रिग्रेशन टेस्टिंग गाइड दो-लैंडस्केप वाला तरीका, अपग्रेड और इम्पैक्ट एनालिसिस कवर करती है।

परफ़ॉर्मेंस टेस्टिंग

परफ़ॉर्मेंस टेस्टिंग go-live से पहले होनी ही चाहिए। सबसे अहम टेस्ट कंकरेंसी टेस्ट हैं, जिनमें कई यूज़र एक ही पल में ट्रांज़ैक्शन चलाते हैं।

जो ट्रांज़ैक्शन एक यूज़र के लिए सही चलता है, वह दो सौ यूज़र्स के लिए टाइम आउट हो सकता है। फ़ंक्शनल टेस्टिंग आपको यह कभी नहीं दिखाएगी। IT लीडर्स के लिए मेरी SAP परफ़ॉर्मेंस टेस्टिंग गाइड लोड, स्ट्रेस और सोक टेस्ट और एक्सेप्टेंस क्राइटेरिया लिखने का तरीका कवर करती है।

कटओवर रिहर्सल

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

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

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

यह प्रयास कई लोगों में बँटा होता है। कंसल्टेंट यूनिट टेस्ट चलाते हैं, टेस्ट टीम SIT तैयार करती और चलाती है, बिज़नेस यूज़र UAT चलाते हैं, और Basis व इंटीग्रेशन टीमें परफ़ॉर्मेंस टेस्टिंग और कटओवर रिहर्सल में सहयोग करती हैं।

डेटा माइग्रेशन इसके साथ-साथ चलता है और अकेले 30 से 40 प्रतिशत प्रयास लेता है। दोनों में भारी ओवरलैप है, क्योंकि हर टेस्ट राउंड को ऐसा माइग्रेट किया गया डेटा चाहिए जो प्रोडक्शन जैसा दिखे।

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

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

छोटा, साफ़-सुथरा टेस्ट डेटा उन्हीं समस्याओं को छिपा देता है जो मायने रखती हैं। जो रिपोर्ट कुछ हज़ार रिकॉर्ड पर सेकंडों में चलती है, वह पूरे साल की पोस्टिंग पर घंटों चल सकती है।

एनवायरनमेंट उतना ही मायने रखता है जितना डेटा। टेस्ट लैंडस्केप Prepare में प्लान कीजिए, तय कीजिए कि राउंड के बीच उसे कैसे रिफ़्रेश किया जाएगा, और प्रोजेक्ट व BAU के बदलावों को अलग रखिए। मेरी SAP टेस्ट डेटा मैनेजमेंट गाइड कॉपी, मास्किंग और सेलेक्टिव टेस्ट डेटा कवर करती है।

ऑटोमेशन पर मेरा नियम सीधा है। जब बड़ी संख्या में ऐसे टेस्ट केस हों जिन्हें व्यापक और बार-बार टेस्टिंग चाहिए, तो ऑटोमेट कीजिए। उससे कम हो, तो मैनुअल टेस्टिंग ठीक है।

ऑटोमेशन का फ़ायदा आम तौर पर सबसे पहले रिग्रेशन में मिलता है, क्योंकि वही टेस्ट हर बदलाव के बाद चलते हैं। UAT ज़्यादातर मैनुअल ही रहता है, क्योंकि उसका उद्देश्य बिज़नेस यूज़र का विवेक है, किसी स्क्रिप्ट का नहीं।

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

टूल तीन समूहों में आते हैं: टेस्ट मैनेजमेंट, फ़ंक्शनल ऑटोमेशन और परफ़ॉर्मेंस टेस्टिंग। जिन टीमों का मैंने नेतृत्व किया है या जिनके साथ काम किया है, उन्होंने Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath और LoadRunner इस्तेमाल किए हैं।

हर समूह क्या करता है और उसमें कौन से प्रोडक्ट आते हैं, यह रहा:

टूल समूह	यह क्या करता है	टीमें आम तौर पर कौन से प्रोडक्ट इस्तेमाल करती हैं
टेस्ट मैनेजमेंट	टेस्ट प्लान, टेस्ट केस, एक्ज़ीक्यूशन रिकॉर्ड, डिफ़ेक्ट और ज़रूरतों तक ट्रेसेबिलिटी	SAP Cloud ALM, SAP Solution Manager, Panaya
फ़ंक्शनल टेस्ट ऑटोमेशन	SAP और non-SAP एप्लिकेशन पर स्क्रिप्टेड या मॉडल-आधारित टेस्ट चलाता है	Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft, UiPath
परफ़ॉर्मेंस टेस्टिंग	एक साथ कई यूज़र्स और प्रोडक्शन वॉल्यूम का सिमुलेशन करता है	OpenText LoadRunner, जो अब OpenText Professional Performance Engineering के नाम से बिकता है

चुनने से पहले कुछ प्रोडक्ट तथ्य जान लेना उपयोगी है।

1. SAP Cloud ALM उन ग्राहकों के लिए शामिल है जिनके पास SAP Enterprise Support है या ऐसा क्लाउड सब्सक्रिप्शन है जिसमें Enterprise Support, cloud editions शामिल है (SAP Support)। इसका टेस्ट मैनेजमेंट टेस्ट की तैयारी, टेस्ट प्लान और एक्ज़ीक्यूशन कवर करता है, जिसमें UAT के लिए मैनुअल टेस्ट केस भी शामिल हैं (SAP Learning)।
2. SAP Solution Manager 7.2 का मेनस्ट्रीम मेंटेनेंस 2027 के अंत में समाप्त होता है, और कुछ फ़ंक्शन के लिए, जिनमें टेस्ट सूट भी है, 2030 के अंत तक वैकल्पिक एक्सटेंडेड मेंटेनेंस मिलता है (SAP Support)।
3. SAP Test Automation by Tricentis SAP का रीसेल किया गया ऑटोमेशन प्रोडक्ट है, जो SAP Cloud ALM से इंटीग्रेटेड है और SAP व थर्ड-पार्टी सिस्टम के लिए बना है (SAP)।
4. LoadRunner OpenText का प्रोडक्ट है। LoadRunner Professional का नाम अब OpenText Professional Performance Engineering है, और यह SAP GUI और SAP Web प्रोटोकॉल सपोर्ट करता है (OpenText)।

अगर आप नया प्रोग्राम शुरू कर रहे हैं, तो टेस्ट मैनेजमेंट Solution Manager के बजाय Cloud ALM में प्लान कीजिए। गहरी तुलना के लिए मेरी SAP टेस्टिंग टूल गाइड पढ़िए।

SAP Cloud ERP public edition (S/4HANA Cloud Public Edition) पर SAP हर ग्राहक को अपने शेड्यूल पर अपग्रेड करता है। SAP Learning हर छह महीने में अपग्रेड बताता है, फ़िलहाल फ़रवरी और अगस्त में, और बीच में हर महीने नए फ़ीचर आते हैं (SAP Learning)।

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

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

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

टेस्ट के नतीजों को मापने योग्य एग्ज़िट क्राइटेरिया के ज़रिए अपने go/no-go फ़ैसलों से जोड़िए। मेरी SAP क्वालिटी गेट्स गाइड इसका तरीका बताती है। अगर आपका प्रोग्राम पहले से मुश्किल में है, तो SAP प्रोग्राम रिकवरी पर मेरे नोट्स बताते हैं कि पहले क्या ठीक करें।

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

SAP टेस्टिंग क्या है?

SAP टेस्टिंग साबित करती है कि कॉन्फ़िगर किया गया SAP सिस्टम आपकी बिज़नेस प्रक्रियाएँ आपके डेटा और आपके वॉल्यूम पर सही चलाता है। S/4HANA प्रोग्राम में इसमें यूनिट टेस्टिंग, सिस्टम इंटीग्रेशन टेस्टिंग, यूज़र एक्सेप्टेंस टेस्टिंग, रिग्रेशन टेस्टिंग, परफ़ॉर्मेंस टेस्टिंग और कटओवर रिहर्सल शामिल हैं। go-live के बाद भी यह हर सपोर्ट बदलाव और रिलीज़ के लिए जारी रहती है।

SAP टेस्टिंग के प्रकार कौन से हैं?

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

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

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

SAP प्रोजेक्ट का कितना हिस्सा टेस्टिंग होता है?

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

क्या SAP टेस्टिंग ऑटोमेट की जानी चाहिए?

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

SAP टेस्टिंग के लिए कौन सा टूल इस्तेमाल होता है?

ज़्यादातर प्रोग्राम एक टेस्ट मैनेजमेंट टूल को एक ऑटोमेशन टूल और एक परफ़ॉर्मेंस टेस्टिंग टूल के साथ जोड़ते हैं। आम विकल्प हैं: टेस्ट मैनेजमेंट के लिए SAP Cloud ALM या Solution Manager, ऑटोमेशन के लिए Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft या UiPath, और परफ़ॉर्मेंस के लिए OpenText LoadRunner। नए प्रोग्राम को Cloud ALM पर योजना बनानी चाहिए, क्योंकि Solution Manager का मेनस्ट्रीम मेंटेनेंस 2027 में समाप्त होता है।