SAP टेस्ट ऑटोमेशन: कहाँ से शुरू करें और कब फ़ायदा मिलता है

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

S/4HANA प्रोग्राम में मैं यही नियम अपनाता हूँ। मेरे अनुभव में टेस्टिंग में प्रोग्राम का लगभग 35 प्रतिशत प्रयास लगता है, इसलिए सवाल कभी यह नहीं होता कि टेस्ट करें या नहीं। सवाल यह है कि उस प्रयास का कौन सा हिस्सा टूल उठाए।

ऑटोमेशन यूनिट, इंटीग्रेशन, एक्सेप्टेंस और परफ़ॉर्मेंस टेस्टिंग के साथ कैसे बैठता है, यह जानने के लिए मेरे परिचय SAP टेस्टिंग क्या है से शुरू कीजिए। यह लेख बताता है कि कहाँ से शुरू करें, ऑटोमेशन कब फ़ायदा देता है, फ़्रेमवर्क कौन से हैं, और SAP Cloud ALM, Solution Manager और Tricentis आपको क्या देते हैं।

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

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

SAP प्रोग्राम में दोहराव कुछ तय जगहों से आता है:

1. ट्रांसपोर्ट। क्वालिटी सिस्टम में जाने वाला हर बदलाव वह चीज़ तोड़ सकता है जो कल तक काम कर रही थी।
2. SAP रिलीज़ और सपोर्ट पैकेज। ऑन-प्रिमाइस और प्राइवेट क्लाउड में अपग्रेड, और SAP S/4HANA Cloud Public Edition पर शेड्यूल्ड अपग्रेड।
3. बार-बार के टेस्ट राउंड। सिस्टम इंटीग्रेशन टेस्टिंग (SIT) एक ही एंड-टू-एंड फ़्लो एक से ज़्यादा राउंड में चलाती है।
4. रोलआउट वेव। एक ग्लोबल टेम्पलेट हर देश या कंपनी कोड के लिए फिर से टेस्ट होता है।
5. डेटा-भारी जाँचें। प्राइसिंग, टैक्स या अकाउंट डिटर्मिनेशन के कई कॉम्बिनेशन, जहाँ केवल डेटा बदलता है।

अगर इनमें से कुछ भी लागू नहीं होता, तो टूल जितना बचाएगा उससे ज़्यादा ख़र्च कराएगा।

तालिका बताती है कि मैं टेस्ट के प्रकार के हिसाब से काम कैसे बाँटूँगा।

टेस्ट का प्रकार	ऑटोमेट करें?	क्यों
order to cash, procure to pay और record to report जैसी मुख्य प्रक्रियाओं का रिग्रेशन	हाँ, सबसे पहले	हर ट्रांसपोर्ट और हर रिलीज़ के बाद चलता है
SIT राउंड	आंशिक रूप से	स्थिर फ़्लो ऑटोमेट कीजिए; नए और बदलते परिदृश्य मैनुअल रखिए
यूज़र एक्सेप्टेंस टेस्टिंग (UAT)	शायद ही कभी	बिज़नेस यूज़र तय करते हैं कि प्रक्रिया उनके लिए काम करती है या नहीं, जो स्क्रिप्ट नहीं कर सकती
एक्सप्लोरेटरी और नेगेटिव टेस्ट	नहीं	इनकी क़ीमत उस इंसान से आती है जो वह खोजता है जो किसी ने स्क्रिप्ट नहीं किया
परफ़ॉर्मेंस और लोड	हाँ, लोड टूल के साथ	एक साथ कई यूज़र हाथ से पैदा नहीं किए जा सकते
एक बार की डेटा माइग्रेशन जाँचें	आम तौर पर नहीं	रिकंसिलिएशन रिपोर्ट यह बेहतर करती हैं, जब तक वही लोड मॉक रन में दोहराया न जाए

Decide

क्या आपको यह SAP टेस्ट ऑटोमेट करना चाहिए

कई टेस्ट केस, हर बदलाव या रिलीज़ के बाद दोहराए जाते हैं

→इसे ऑटोमेट कीजिए

कम टेस्ट केस, या एक-दो बार ही चलते हैं

→इसे मैनुअल टेस्ट कीजिए

प्रोसेस डिज़ाइन अभी बदल रहा है

→स्थिर होने तक रुकिए, फिर तय कीजिए

जो ऑटोमेशन निराश करता है, वह आम तौर पर बहुत चौड़ा शुरू हुआ होता है: सब कुछ, डिज़ाइन के दौरान, और नतीजे की ज़िम्मेदारी किसी की नहीं। मैं यह क्रम अपनाऊँगा:

1. वे प्रक्रियाएँ चुनिए जिनका टूटना बिज़नेस बर्दाश्त नहीं कर सकता। मंथ-एंड क्लोज़, बिलिंग, पेमेंट और कई साइट पर रोलआउट होने वाली हर चीज़, अच्छी-लगने-वाली रिपोर्ट से पहले आती है।
2. पहले टेस्ट मैनुअल चलाइए। टूल उस टेस्ट को ऑटोमेट करता है जो हाथ से पहले से काम करता है। वह आपके लिए टेस्ट डिज़ाइन नहीं करता।
3. स्थिर डिज़ाइन का इंतज़ार कीजिए। Explore या शुरुआती Realize में ऑटोमेट करने का मतलब है हर डिज़ाइन फ़ैसला बदलने पर टेस्ट दोबारा बनाना।
4. एक छोटा रिग्रेशन पैक बनाइए। महत्वपूर्ण प्रक्रियाओं को शुरू से अंत तक कवर कीजिए, फिर क्वालिटी सिस्टम में आने वाले हर ट्रांसपोर्ट पर पैक चलाइए।
5. मेंटेनेंस के लिए एक ज़िम्मेदार व्यक्ति तय कीजिए। स्क्रीन, रोल या डेटा बदलने पर किसी को टेस्ट ठीक करने होंगे, वरना पैक कुछ ही रिलीज़ में बेकार हो जाता है।
6. कवरेज वहीं बढ़ाइए जहाँ दोहराव उसे उचित ठहराए। टेस्ट तब जोड़िए जब वह अक्सर चलेगा, इसलिए नहीं कि कोई कवरेज लक्ष्य ऐसा कहता है।

प्रोजेक्ट को बिज़नेस ऐज़ यूज़ुअल से अलग रखिए

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

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

अपने प्रोग्राम में मैंने Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath और LoadRunner इस्तेमाल किए हैं, या मेरी टीमों ने इन्हें इस्तेमाल किया है। यह लेख इनकी रैंकिंग नहीं करता। सही चुनाव आपके लैंडस्केप, आपके सपोर्ट कॉन्ट्रैक्ट और इस पर निर्भर करता है कि टेस्ट कौन मेंटेन करेगा।

शुरुआत उससे कीजिए जो SAP पहले से देता है, क्योंकि उसके कुछ हिस्से का भुगतान शायद आप पहले ही कर चुके हैं।

SAP Cloud ALM

SAP Cloud ALM टेस्ट मैनेजमेंट की परत है। यह आपकी प्रक्रियाओं और ज़रूरतों के सामने मैनुअल और ऑटोमेटेड टेस्ट की योजना बनाता है, उन्हें चलाता है और ट्रेस करता है। SAP Enterprise Support, Product Support for Large Enterprises या किसी योग्य क्लाउड सब्सक्रिप्शन वाले ग्राहक एक टेनेंट प्रोविज़न कर सकते हैं (SAP usage rights)।

यह ख़ुद ऑटोमेटेड टेस्ट नहीं चलाता। SAP कहता है कि Cloud ALM में अपना बनाया हुआ ऑटोमेशन इंजन नहीं है और उसके ALM प्लेटफ़ॉर्म थर्ड-पार्टी टेस्ट ऑटोमेशन के लिए खुले रहते हैं (SAP Support, test automation)।

SAP की सेटअप गाइड बिल्ट-इन इंटीग्रेशन के साथ अन्य प्रोवाइडर के लिए एक सार्वजनिक Test Automation API बताती है (SAP Help Portal)। Panaya और UiPath ऑटोमेटेड टेस्ट केस के लिए Cloud ALM इंटीग्रेशन का दस्तावेज़ देते हैं। Worksoft अपने इंटीग्रेशन में Cloud ALM और Solution Manager गिनाता है, और OpenText अपने क्लाउड परफ़ॉर्मेंस टेस्टिंग प्रोडक्ट के लिए Cloud ALM इंटीग्रेशन देता है।

Tricentis Test Automation for SAP और SAP Test Automation by Tricentis

कुछ भी ख़रीदने से पहले अपना एंटाइटलमेंट जाँचिए। SAP, Cloud ALM से इंटीग्रेटेड Tricentis Test Automation for SAP का टर्म लाइसेंस SAP Enterprise Support, Enterprise Support cloud editions और Product Support for Large Enterprises के साथ देता है। यह फ़िलहाल 31 दिसंबर 2028 तक चलता है (SAP usage rights)।

सीमाएँ सख़्त हैं: 5 नामित यूज़र, हर कैलेंडर महीने 500 टेस्ट रन, 5 ग्राहक-प्रबंधित एक्ज़ीक्यूशन एजेंट और 12 महीने तक नतीजों का रिटेंशन। इसे प्रोडक्टिव बिज़नेस प्रक्रियाओं को ऑटोमेट करने के लिए इस्तेमाल नहीं किया जा सकता। इसे शुरुआत का एक ज़रिया मानिए, प्रोग्राम-स्तर का टूल नहीं।

SAP Test Automation by Tricentis इसके ऊपर का पेड विकल्प है। यह एक software-as-a-service प्रोडक्ट है जिसे SAP एक solution extension के रूप में बेचता और सपोर्ट करता है, और यह SAP व थर्ड-पार्टी एप्लिकेशन कवर करता है। जब एंटाइटलमेंट की गुंजाइश ख़त्म हो जाती है, तो यह Cloud ALM के साथ मिलने वाली Tricentis क्षमता को आगे बढ़ाता है।

SAP Solution Manager

Solution Manager 7.2 का मेनस्ट्रीम मेंटेनेंस 2027 के अंत तक चलता है। जो ग्राहक SAP Business Suite 7 के एक्सटेंडेड मेंटेनेंस का विकल्प चुनते हैं, उन्हें Solution Manager का एक्सटेंडेड मेंटेनेंस 2030 के अंत तक मिलता है। यह सीमित क्षेत्रों को कवर करता है, जिनमें टेस्ट सूट भी है (SAP Support)।

इसका अपना ऑटोमेशन, Component-Based Test Automation (CBTA), SAP क्लाउड प्रोडक्ट तक नहीं बढ़ाया जाएगा। Solution Manager इंटीग्रेशन के लिए Tricentis लाइसेंस फ़िलहाल 31 दिसंबर 2027 तक चलता है। अगर आप पहले से Solution Manager चला रहे हैं, तो लैंडस्केप के आगे बढ़ने तक उसे रखिए, पर उसके इर्द-गिर्द नया ऑटोमेशन मत बनाइए।

SAP S/4HANA Cloud Public Edition

Public Edition के साथ उसका अपना Test Automation Tool आता है। SAP की सलाह है कि पार्टनर हर प्रक्रिया कॉन्फ़िगर करते समय टेस्ट ऑटोमेट्स बनाएँ या अपडेट करें, ताकि वे अपग्रेड के दौरान टेस्ट सिस्टम में चल सकें (SAP Learning)।

आपकी सहमति से SAP स्टैंडर्ड, बिना बदली गई प्रक्रियाओं पर अपग्रेड के बाद के टेस्ट चलाता है। go-live के बाद आपने जो कुछ भी कस्टमाइज़ किया है, उसकी रिग्रेशन टेस्टिंग आपकी ज़िम्मेदारी है, अपने ऑटोमेट्स के साथ।

तालिका ऊपर बताए गए टूल को काम के हिसाब से समेटती है, पसंद के हिसाब से नहीं।

टूल	मुख्य काम	कहाँ ठीक बैठता है
SAP Cloud ALM	टेस्ट मैनेजमेंट और ऑर्केस्ट्रेशन	नए प्रोग्राम; मैनुअल और ऑटोमेटेड टेस्ट को प्रक्रियाओं से जोड़ता है
SAP Solution Manager	टेस्ट मैनेजमेंट, ऑन-प्रिमाइस	जिन लैंडस्केप में यह पहले से चल रहा है; मेनस्ट्रीम मेंटेनेंस 2027 में समाप्त
Tricentis Tosca और SAP Test Automation by Tricentis	मॉडल-आधारित ऑटोमेशन	SAP और non-SAP एप्लिकेशन; SAP द्वारा रीसेल और सपोर्ट किया जाता है
Worksoft	कोडलेस प्रोसेस ऑटोमेशन	Cloud ALM और Solution Manager से इंटीग्रेट होता है
Panaya	टेस्ट मैनेजमेंट और कोडलेस ऑटोमेशन	ऑटोमेटेड टेस्ट के लिए Cloud ALM इंटीग्रेशन
UiPath	Test Manager वाला ऑटोमेशन प्लेटफ़ॉर्म	ऑटोमेटेड टेस्ट केस के लिए Cloud ALM इंटीग्रेशन
OpenText LoadRunner	परफ़ॉर्मेंस और लोड टेस्टिंग	go-live से पहले कंकरेंसी और वॉल्यूम टेस्ट

Xray for Jira समेत गहरी तुलना के लिए मेरी SAP टेस्टिंग टूल गाइड पढ़िए। लोड टेस्टिंग के लिए IT लीडर्स के लिए SAP परफ़ॉर्मेंस टेस्टिंग पढ़िए।

टूल से ज़्यादा यह मायने रखता है कि टेस्ट कैसे बनाए जाते हैं और उन्हें मेंटेन कौन करता है। ज़्यादातर SAP ऑटोमेशन इनमें से किसी एक तरीके में आता है:

1. मॉडल-आधारित। स्क्रीन और API को स्कैन करके दोबारा इस्तेमाल होने वाले मॉड्यूल बनाए जाते हैं, फिर उन्हें जोड़कर टेस्ट केस बनते हैं। फ़ंक्शनल कंसल्टेंट बिना कोड के इन्हें बना और पढ़ सकते हैं।
2. कोडलेस प्रोसेस कैप्चर। बिज़नेस प्रक्रिया के चरण रिकॉर्ड करके दोबारा इस्तेमाल होने वाले टेस्ट में बदले जाते हैं। यह उन टीमों के लिए ठीक है जहाँ की-यूज़र रिग्रेशन पैक बनाने में मदद करते हैं।
3. कोड-आधारित। टेस्ट इंजीनियर किसी प्रोग्रामिंग फ़्रेमवर्क में टेस्ट लिखते हैं। यह किसी डेवलपमेंट टीम के Fiori ऐप और API के लिए ठीक है, और इसे मेंटेन करने के लिए डेवलपर चाहिए।
4. टेस्टिंग मॉड्यूल वाले रोबोटिक प्रोसेस ऑटोमेशन प्लेटफ़ॉर्म। बिज़नेस ऑटोमेशन और टेस्ट ऑटोमेशन के लिए एक ही प्लेटफ़ॉर्म, उपयोगी अगर आप उसे पहले से चला रहे हैं।
5. SAP के दिए ऑटोमेट्स। Public Edition पर Test Automation Tool के साथ आने वाले टेस्ट ऑटोमेट्स, जिन्हें आपके डेटा और बदलावों के हिसाब से ढाला जाता है।

आप जो भी तरीका चुनें, तीन डिज़ाइन फ़ैसले तय करते हैं कि टेस्ट टिकेंगे या नहीं:

1. जहाँ हो सके, API स्तर पर टेस्ट कीजिए। API टेस्ट उन टेस्ट से कम टूटते हैं जो स्क्रीन पर क्लिक करते चलते हैं।
2. टेस्ट डेटा को रीसेट करने योग्य रखिए। जो टेस्ट पिछले रन में इस्तेमाल हो चुके डेटा पर निर्भर है, वह ग़लत वजह से फ़ेल होता है।
3. साझा मॉड्यूल से बनाइए। जब कोई स्क्रीन बदलती है, तो आप एक मॉड्यूल ठीक करते हैं, उसे छूने वाला हर टेस्ट नहीं।

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

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

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

अस्थिर टेस्ट ठीक कीजिए, जिन टेस्ट को कोई नहीं चलाता उन्हें हटाइए, और पैक को इतना छोटा रखिए कि लोग उसके नतीजों पर भरोसा करें।

ऑटोमेशन को किसी टेस्ट प्लान के भीतर भी होना चाहिए। साइकिल, एंट्री और एग्ज़िट क्राइटेरिया और भूमिकाएँ पहले आती हैं; मेरी S/4HANA टेस्टिंग स्ट्रैटेजी इन्हें तय करती है।

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

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

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

SAP टेस्ट ऑटोमेशन क्या है?

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

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

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

क्या SAP Cloud ALM टेस्ट ऑटोमेशन करता है?

यह ऑटोमेटेड टेस्ट मैनेज और ट्रिगर करता है, पर इसका अपना ऑटोमेशन इंजन नहीं है। यह Tricentis Test Automation for SAP से, S/4HANA Cloud Public Edition के Test Automation Tool से, और एक सार्वजनिक Test Automation API के ज़रिए अन्य प्रोवाइडर से इंटीग्रेट होता है।

SAP Test Automation by Tricentis क्या है?

यह एक software-as-a-service टेस्ट ऑटोमेशन प्रोडक्ट है जिसे SAP एक solution extension के रूप में बेचता और सपोर्ट करता है, और यह SAP व थर्ड-पार्टी एप्लिकेशन कवर करता है। यह SAP Enterprise Support के साथ मिलने वाले शुरुआती Tricentis Test Automation for SAP लाइसेंस को आगे बढ़ाता है। उस लाइसेंस की सीमा 5 नामित यूज़र और हर महीने 500 टेस्ट रन है।

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

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

क्या मुझे टेस्ट ऑटोमेशन के लिए अब भी SAP Solution Manager इस्तेमाल करना चाहिए?

केवल तभी, जब वह पहले से आपके लैंडस्केप में चल रहा हो। Solution Manager 7.2 का मेनस्ट्रीम मेंटेनेंस 2027 में समाप्त होता है, और इसका CBTA ऑटोमेशन SAP क्लाउड प्रोडक्ट तक नहीं बढ़ाया जाएगा। नया ऑटोमेशन Cloud ALM के इर्द-गिर्द प्लान कीजिए।