SAP रिग्रेशन टेस्टिंग: अपग्रेड, रिलीज़ और स्कोप

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

इसके ट्रिगर हैं ट्रांसपोर्ट, अपग्रेड और क्लाउड रिलीज़। SAP Cloud ERP public edition पर अपग्रेड की तारीख़ें SAP तय करता है, इसलिए रिलीज़ आने से पहले आपका रिग्रेशन सूट तैयार होना चाहिए।

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

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

रिग्रेशन टेस्टिंग उन प्रक्रियाओं पर टेस्ट दोबारा चलाती है जिन्हें बदलना नहीं था। फ़ंक्शनल टेस्टिंग पूछती है कि नई चीज़ काम करती है या नहीं, जबकि रिग्रेशन पूछता है कि बाकी सब अब भी काम करता है या नहीं।

यह सिस्टम के पूरे जीवनकाल में लागू होती है, सिर्फ़ प्रोग्राम के दौरान नहीं:

1. ट्रांसपोर्ट। डेवलपमेंट से क्वालिटी में जाने वाला हर बदलाव उन प्रक्रियाओं के लिए रिग्रेशन जोखिम है जिन्हें वह छूता है।
2. सपोर्ट पैकेज और feature pack। SAP के सुधार और नए फ़ीचर आपके कॉन्फ़िगरेशन के नीचे का स्टैंडर्ड कोड बदलते हैं।
3. रिलीज़ अपग्रेड। नई रिलीज़ पर जाना, या ऐसी क्लाउड रिलीज़ जिसका शेड्यूल आपने तय नहीं किया, एक साथ कहीं ज़्यादा बदल देती है।
4. कन्वर्ज़न। ECC से S/4HANA कन्वर्ज़न आपका कॉन्फ़िगरेशन और कस्टम कोड रखता है, इसलिए जो कुछ आपने रखा है उसे दोबारा टेस्ट करना होगा। मेरी ECC से S/4HANA माइग्रेशन गाइड बताती है कि यह प्लान में कहाँ आता है।
5. इंटीग्रेशन और एक्सटेंशन। किसी जुड़े हुए सिस्टम या side-by-side एक्सटेंशन में बदलाव बिना किसी SAP ट्रांसपोर्ट के SAP की तरफ़ कुछ तोड़ सकता है।

रिग्रेशन सूट को नए फ़ंक्शन के लिए लिखे गए टेस्ट से अलग रखिए। सूट उन प्रक्रियाओं की एक स्थिर लाइब्रेरी है जिन्हें बिज़नेस खोना बर्दाश्त नहीं कर सकता, जैसे order to cash, procure to pay और मंथ-एंड क्लोज़।

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

Public edition: साल में दो अपग्रेड

SAP Cloud ERP public edition, जिसे पहले S/4HANA Cloud Public Edition कहा जाता था, को साल में दो बड़े अपग्रेड मिलते हैं, फ़रवरी और अगस्त में। इनके बीच छोटी फ़ीचर डिलीवरी आती हैं।

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

SAP का अपग्रेड के बाद की और रिग्रेशन टेस्टिंग पर Cloud ALM कोर्स सलाह देता है कि Cloud ALM में एक रिग्रेशन टेस्ट प्लान बनाइए और हर रिलीज़ के लिए उसी को दोबारा इस्तेमाल कीजिए। Public edition में पहले से दी गई टेस्ट स्क्रिप्ट वाला एक मुफ़्त टेस्ट ऑटोमेशन टूल भी शामिल है, इसलिए स्टैंडर्ड प्रक्रियाओं के लिए शुरुआत का एक आधार मौजूद है।

Private edition: दो साल का रिलीज़ साइकिल

SAP Cloud ERP Private, यानी RISE with SAP के ज़रिए बिकने वाला private edition, ऑन-प्रिमाइस रिलीज़ साइकिल पर चलता है। SAP Learning के अनुसार हर दो साल में एक नई बेस रिलीज़ आती है, उसके बाद हर छह महीने feature pack stack आते हैं, और हर रिलीज़ को सात साल का मेनस्ट्रीम मेंटेनेंस मिलता है।

मेनस्ट्रीम मेंटेनेंस में बने रहने के लिए आपको हर सात साल में कम से कम एक अपग्रेड इंस्टॉल करना होगा, और RISE आपको साल में एक अपग्रेड का अनुरोध करने देता है। टेक्निकल अपग्रेड SAP करता है, पर योजना, तैयारी और टेस्टिंग ग्राहक या पार्टनर का काम रहता है।

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

यह तालिका रिग्रेशन के ट्रिगर अगल-बगल रखती है:

बदलाव	कितनी बार	तारीख़ कौन तय करता है	रिग्रेशन रन को क्या कवर करना चाहिए
क्वालिटी में ट्रांसपोर्ट	रोज़ या हर हफ़्ते	आपकी टीम	वे प्रक्रियाएँ जिन्हें बदले गए ऑब्जेक्ट छूते हैं
Public edition अपग्रेड	साल में दो बार, फ़रवरी और अगस्त	SAP	स्कोप की हर प्रक्रिया, कस्टम लॉजिक पहले, प्रोडक्शन से पहले की विंडो में
Private edition feature pack stack	हर छह महीने, अगर आप लेते हैं	आप, SAP के शेड्यूल के भीतर	आपके इस्तेमाल वाले बदले हुए स्टैंडर्ड फ़ंक्शन, साथ में कस्टम कोड
Private edition रिलीज़ अपग्रेड	कम से कम हर सात साल में, RISE में अनुरोध पर साल में एक तक	आप, SAP के साथ	पूरा सूट, कस्टम कोड और इंटीग्रेशन
ECC से S/4HANA कन्वर्ज़न	एक बार	आप	जो कुछ आपने रखा है

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

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

आपको ये टूल मिलेंगे:

1. SAP Solution Manager। Test Suite का हिस्सा Business Process Change Analyzer दिखाता है कि कोई बदलाव किन बिज़नेस प्रक्रियाओं को प्रभावित करता है। Scope and Effort Analyzer किसी सपोर्ट पैकेज या enhancement package के इंस्टॉल होने से पहले उसके असर का अनुमान लगाता है, और SAP इसे एक प्लानिंग टूल कहता है।
2. SAP Cloud ALM। Cloud ALM रिग्रेशन टेस्ट प्लान, एक्ज़ीक्यूशन और डिफ़ेक्ट मैनेज करता है, और ऑटोमेशन टूल से जुड़ता है। Public edition अपग्रेड के लिए SAP का Release Assessment and Scope Dependency टूल दिखाता है कि किसी रिलीज़ के कौन से बदलाव आपके स्कोप को प्रभावित करते हैं।
3. Tricentis LiveCompare। LiveCompare दस्तावेज़ के अनुसार यह टेस्ट करने के लिए सबसे ज़्यादा जोखिम वाले ऑब्जेक्ट का एक न्यूनतम सेट पहचानता है, फिर आपकी टेस्ट रिपॉज़िटरी के सामने test hits और test gaps की रिपोर्ट देता है। SAP इसे SAP Change Impact Analysis by Tricentis के नाम से रीसेल करता है, और यह Tricentis Tosca से इंटीग्रेट होता है।
4. Panaya। Panaya का SAP अपग्रेड प्रोडक्ट चेंज इम्पैक्ट एनालिसिस, कोड करेक्शन, टेस्ट मैनेजमेंट और ऑटोमेशन को जोड़ता है, और S/4HANA वर्ज़न, feature pack stack और support package stack कवर करता है।

इस पर कुछ बनाने से पहले देखिए कि आपका Solution Manager कहाँ खड़ा है। SAP Support कहता है कि Solution Manager 7.2 का मेनस्ट्रीम मेंटेनेंस 2027 के अंत में समाप्त होता है। जो ग्राहक Business Suite 7 का एक्सटेंडेड मेंटेनेंस लेते हैं, उनके पास यह 2030 के अंत तक रहता है, और SAP 2027 के अंत से पहले Cloud ALM पर जाने की सलाह देता है।

इम्पैक्ट एनालिसिस स्कोप को छोटा करता है। अकेले वह स्कोप तय नहीं करता, इसलिए बिज़नेस के लिए अहम प्रक्रियाओं का एक मूल सेट रखिए जो हर बार चले, टूल चाहे जो कहे।

SAP टेस्टिंग और वैलिडेशन टूल की मेरी तुलना बताती है कि ये प्रोडक्ट आपस में कैसे बैठते हैं और आपके SAP सपोर्ट कॉन्ट्रैक्ट में पहले से क्या शामिल है।

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

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

Public edition का ग्राहक जो साल में दो बार पूरा सूट चलाता है, और बीच में ट्रांसपोर्ट भी, वह इस सीमा तक जल्दी पहुँच जाता है। साल में कुछ ही बार बदलने वाला एक छोटा private edition सिस्टम शायद न पहुँचे।

ख़रीदने से पहले ये सवाल पूछिए:

1. आपके पास कितने रिग्रेशन टेस्ट केस हैं, और उनमें से कितने हर साइकिल में चलते हैं?
2. आप उन्हें कितनी बार चलाते हैं, ट्रांसपोर्ट, feature pack और अपग्रेड गिनकर, सिर्फ़ रिलीज़ अपग्रेड नहीं?
3. एक मैनुअल रन में कितना समय लगता है, और क्या वह रिग्रेशन विंडो में समा जाता है?
4. स्क्रीन और प्रक्रियाएँ बदलने पर स्क्रिप्ट कौन मेंटेन करेगा?

स्क्रिप्ट मेंटेनेंस वह लागत है जिसे लोग कम आँकते हैं। जिस ऑटोमेटेड सूट को कोई अपडेट नहीं करता, वह ऐसी वजहों से फ़ेल होता है जिनका सिस्टम से कोई लेना-देना नहीं, और टीम उस पर भरोसा करना छोड़ देती है।

जिन प्रोग्राम का मैंने नेतृत्व किया है, उनमें मेरी टीमों ने Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager और UiPath इस्तेमाल किए हैं। चुनाव अपने सिस्टम और अपनी टीम के साथ मेल के आधार पर कीजिए, डेमो के आधार पर नहीं। मेरी SAP टेस्ट ऑटोमेशन गाइड बताती है कि कहाँ से शुरू करें और लागत की वसूली कैसे आँकें।

SAP प्रोग्राम में रिग्रेशन की सबसे कठिन समस्या टूलिंग नहीं है। यह है बदलाव की दो धाराओं का एक ही समय में एक ही सिस्टम से गुज़रना।

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

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

प्रोजेक्ट लैंडस्केपBAU लैंडस्केप

इससे क्या गुज़रता हैप्रोजेक्ट लैंडस्केपप्रोग्राम के नए फ़ंक्शन, कॉन्फ़िगरेशन और कस्टम कोडBAU लैंडस्केपलाइव सिस्टम के सुधार और छोटे बदलाव

रिग्रेशन का फ़ोकसप्रोजेक्ट लैंडस्केपवे प्रक्रियाएँ जिन्हें प्रोग्राम बदलता है, साथ में मूल सूटBAU लैंडस्केपवे प्रक्रियाएँ जिन्हें हर सुधार छूता है, साथ में मूल सूट

प्रोडक्शन में कब जाता हैप्रोजेक्ट लैंडस्केपgo-live पर या किसी रिलीज़ वेव मेंBAU लैंडस्केपसपोर्ट रिलीज़ के रूप में, सामान्य शेड्यूल पर

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

शुरुआत से ही इसकी योजना बनाइए:

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

दूसरे लैंडस्केप में पैसा लगता है, पर उस go-live में भी लगता है जहाँ कोई नहीं बता पाता कि बिलिंग किस बदलाव ने तोड़ी। मेरी S/4HANA टेस्टिंग स्ट्रैटेजी दिखाती है कि रिग्रेशन साइकिल इंटीग्रेशन और यूज़र एक्सेप्टेंस टेस्टिंग के साथ कहाँ बैठते हैं।

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

वह संख्या बताती है कि अगली अपग्रेड विंडो यथार्थवादी है या नहीं और ऑटोमेशन का फ़ायदा होगा या नहीं। अगर आप प्रोग्राम के बीच में हैं, तो जाँचिए कि प्रोजेक्ट और BAU के बदलाव प्रोडक्शन तक एक ही रास्ता साझा करते हैं या नहीं।

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

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

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

SAP Cloud ERP public edition को कितनी बार रिग्रेशन टेस्टिंग चाहिए?

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

RISE with SAP private edition अपग्रेड पर रिग्रेशन टेस्टिंग कौन करता है?

टेक्निकल अपग्रेड SAP करता है। योजना, तैयारी और टेस्टिंग ग्राहक या इम्प्लीमेंटेशन पार्टनर के पास रहती है, इसलिए रिग्रेशन के प्रयास का बजट सब्सक्रिप्शन से अलग बनाइए।

SAP रिग्रेशन टेस्टिंग का स्कोप तय करने में कौन से टूल मदद करते हैं?

इम्पैक्ट एनालिसिस टूल तुलना करते हैं कि क्या बदला और आप क्या इस्तेमाल करते हैं। आम विकल्प हैं SAP Solution Manager में Business Process Change Analyzer और Scope and Effort Analyzer, और public edition के लिए Release Assessment and Scope Dependency टूल। Tricentis LiveCompare और Panaya यही काम करते हैं, जबकि SAP Cloud ALM रिग्रेशन टेस्ट प्लान और एक्ज़ीक्यूशन मैनेज करता है।

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

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

लाइव सिस्टम को सपोर्ट करते हुए SAP प्रोग्राम के दौरान रिग्रेशन टेस्ट कैसे करें?

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