सेल्सफोर्स चाचणी संघांच्या अपेक्षेपेक्षा अधिक सहजपणे का खंडित होते

0

प्रत्येक सेल्सफोर्स टीम या आव्हानांचा कधीतरी अनुभव घेते. चाचणी वातावरणात कोड परिपूर्ण होता… QA टीमने बिल्डला आधीच मंजुरी दिली आहे… तैनाती कोणत्याही त्रुटीशिवाय होती… आणि नंतर… दोन दिवसांनी, कॉल्स येऊ लागले.

ग्राहक केस सादर करू शकत नाही.
कोट मंजूरी लूपमध्ये जात आहे.
काल डेटा दाखवला तरीही डॅशबोर्ड आज कोणताही डेटा दाखवत नाही.

“येथे कोणीही कशाला हात लावला नाही!” तुमच्या संस्थेतील प्रत्येकजण जे म्हणतो तेच असते. आणि प्रामाणिकपणे, ते खरे वाटू शकते.

हे सर्वात मोठे आव्हान आहे सेल्सफोर्स चाचणी खोटे हे मूक अपयश किंवा समस्या आहेत ज्या त्रुटी किंवा चेतावणी दर्शवत नाहीत.

सेल्सफोर्स सिस्टम सहसा मोठ्या आणि मोठ्या प्रमाणात सानुकूलित असतात. त्यामुळे, तुमचा कोड बदलला नसला तरीही, आज काम केलेले चाचणी केस उद्या खंडित होऊ शकते.

या अपयशांचे कारण काय आहे हे स्पष्टपणे समजल्यावरच तुम्ही व्यावहारिक चाचणी योजना तयार करू शकता.

Salesforce चाचणी म्हणजे काय

सर्वप्रथम, सरावात सेल्सफोर्स चाचणी म्हणजे काय हे आपण समजून घेतले पाहिजे.

Salesforce हे एकल सॉफ्टवेअर नाही. हा एकात्मिक प्रणालींचा समूह आहे जेथे अनेक ढग परस्परसंवाद करतात:

● लीड्स, संधी आणि सौद्यांसाठी सेल्स क्लाउड

● केसेस आणि सपोर्टसाठी सर्व्हिस क्लाउड

● मोहिमांसाठी मार्केटिंग क्लाउड इ.

एजंटफोर्स सारखी त्याची AI वैशिष्ट्ये मानवी इनपुटसह जटिल कार्यांना समर्थन देतात.

म्हणून, Salesforce चाचणी म्हणजे खालील गोष्टी एकाच वेळी योग्यरित्या कार्य करत आहेत याची खात्री करणे:

● प्लॅटफॉर्म: पायाभूत सुविधा

● सानुकूलन: तुम्ही बदललेले किंवा सेट केलेले घटक

● ऑटोमेशन: स्वयंचलित कार्यप्रवाह

● एकत्रीकरण: इतर अनुप्रयोगांसह संप्रेषण

हे फक्त UI च्या चाचणीच्या पलीकडे जाते आणि चाचणी समाविष्ट करते:

● युनिट चाचण्यांमध्ये सर्वोच्च वर्ग

● सेल्सफोर्स आणि इतर प्रणालींमधील एकत्रीकरणाची चाचणी करत आहे

● प्रत्येक रीलिझमध्ये रीग्रेशन चाचणी करणे

● पूर्ण व्यवसाय प्रवाहाची एंड-टू-एंड चाचणी करणे (बंद होण्याची संधी, ऑर्डर प्लेसमेंटला कोट मंजूरी) इ.

तुमच्या प्रकाशन प्रक्रियेशी पूर्णपणे संबंधित नसलेल्या कारणांमुळे यातील प्रत्येक स्तर वैयक्तिकरित्या अयशस्वी होऊ शकतो.

पाच स्ट्रक्चरल कारणे Salesforce चाचणी खंडित

प्लॅटफॉर्म वर्षातून तीन वेळा रिलीज होतो आणि तुमच्या चाचण्या नेहमीच टिकत नाहीत

Salesforce दर वर्षी तीन प्रमुख प्लॅटफॉर्म अद्यतने जारी करते: वसंत ऋतु, उन्हाळा आणि हिवाळी प्रकाशन. हे केवळ पर्यायी अद्यतने किंवा पार्श्वभूमीत होणारी किरकोळ देखभाल नाहीत. हे बदल जगभरातील सर्व ग्राहक संस्थांना आपोआप आणले जातात.

या प्रकाशनांमध्ये काय बदल होत आहेत? काहीवेळा लाइटनिंग घटक कसे कार्य करतात त्यात बदल होतो. काहीवेळा तो एपीआय संरचनेतील बदल किंवा स्क्रीनवरील एक छोटा UI बदल असतो. प्लॅटफॉर्मचे भाग ओळखण्यासाठी तुमच्या चाचणी स्क्रिप्ट वापरत असलेले निवडक कदाचित असंबद्ध होऊ शकतात. म्हणजेच ते एकाच ठिकाणी नसतील किंवा बदलले असतील. थोडक्यात, गेल्या तिमाहीत उत्तम प्रकारे काम करणारे ऑटोमेशन या तिमाहीत अयशस्वी होत आहे, तुमच्या टीमने काहीतरी बदलले म्हणून नाही तर तुम्ही ज्या प्लॅटफॉर्मवर आहात ते बदलले आहे म्हणून.

सेल्सफोर्स रिलीझला फक्त नवीन वैशिष्ट्यांसह व्यवसाय इव्हेंट म्हणून पाहणाऱ्या टीमकडे बरेचदा काम करावे लागते. जर ते त्यांना तांत्रिक इव्हेंट म्हणून पाहत नाहीत ज्यासाठी योग्य प्रतिगमन चक्र आवश्यक आहे, उत्पादनामध्ये समस्या शोधल्या जातील. आणि सर्वात वाईट वेळी!

त्यामुळे, तुमच्या रोडमॅपमधील प्रत्येक सेल्सफोर्स रिलीझशी सुसंगत असलेल्या चाचणी चक्रांचा समावेश करणे पर्यायी नाही, परंतु एक गरज आहे.

लाइटनिंग वेब घटक Ui ला दिसते त्यापेक्षा जास्त कठीण करतात

सेल्सफोर्सच्या आधुनिक UI फ्रेमवर्क, लाइटनिंग वेब कॉम्पोनंट्स (LWC) अंतर्गत डिझाइन निवडीमध्ये शॅडो DOM एन्कॅप्युलेशनची अंमलबजावणी समाविष्ट आहे.

आर्किटेक्चर उत्कृष्ट आहे, प्रत्येक घटकासाठी शैली आणि स्क्रिप्ट इतर सर्वांपेक्षा वेगळ्या ठेवून, एक मोठा UI तयार करताना कमी त्रुटी-प्रवण प्रक्रिया सुनिश्चित करते. परंतु ते त्यांच्या कोडची चाचणी घेत असलेल्या विकसकांसाठी एक महत्त्वपूर्ण वेदना बिंदू आहे.

बहुतेक चाचणी ऑटोमेशन फ्रेमवर्क CSS निवडक किंवा XPath क्वेरीच्या वापरावर अवलंबून असतात आणि समस्या अशी आहे की बहुतेक या सावली DOM सीमा ओलांडण्याच्या क्षमतेस समर्थन देत नाहीत. जरी CSS किंवा XPath पूर्णपणे वैध असले तरीही, इच्छित घटकांपैकी कोणतेही परत केले जाणार नाहीत. असे नाही की घटक अस्तित्वात नाहीत. त्याऐवजी, ते एका छाया रूटमध्ये राहतात ज्यामध्ये चाचणी फ्रेमवर्क प्रवेश करू शकत नाही.

सेल्सफोर्स क्लासिकमधून लाइटनिंग एक्सपिरियन्समध्ये स्थलांतर केल्यानंतर अनेक संस्था हाताळतात ही एक प्रमुख समस्या आहे. ऍप्लिकेशनच्या शेवटच्या वापरकर्त्यासाठी, इंटरफेस अगदी छान दिसतो, आणि ते ते सहजपणे वापरू शकतात, तरीही जेव्हा तुम्ही पृष्ठाचे स्वयंचलित सत्यापन करण्यासाठी चाचणी कोड चालवता तेव्हा तुम्हाला फक्त रिक्त पृष्ठ मिळते.

चाचणी ऑटोमेशनच्या संदर्भात, सर्वकाही उपस्थित आणि उत्तम प्रकारे उपलब्ध आहे. हे फक्त दृष्टीआड झाले आहे.

Salesforce उदाहरणावरील खोट्या सकारात्मकतेचा सर्वात सामान्य स्त्रोतांपैकी एक (कार्यरत वापरकर्ता इंटरफेस तपासण्यात अक्षमता) थेट शॅडो DOM घटकांशी संबंधित आहे. हे निश्चितपणे लागू केलेल्या वैशिष्ट्य कार्यक्षमतेच्या एकूण गुणवत्तेचे प्रतिबिंब नाही.

कॉन्फिगरेशन बदल स्पष्ट कारणांशिवाय चाचणी खंडित करतात

सेल्सफोर्सला इतर सॉफ्टवेअर प्रणालींपेक्षा वेगळे काय सेट करते ते म्हणजे ऍप्लिकेशनची बरीच कार्यक्षमता कॉन्फिगरेशनद्वारे नियंत्रित केली जाते, कोड नाही.

रेकॉर्ड स्क्रीनवर कोणती फील्ड दृश्यमान आहेत हे पृष्ठ लेआउट निर्धारित करतात. प्रमाणीकरण नियम निर्धारित करतात की कोणता डेटा जतन केला जातो. कोण काय पाहू शकते हे परवानगी सेट ठरवते. काय करायचे ते गुंतागुंतीचे असायचे शिखर कोड आता सहज करता येते वाहते. सेल्सफोर्स ॲडमिन इंटरफेसमधील काही क्लिक्ससह हे सर्व बदलले जाऊ शकते. कोड उपयोजन, पुल विनंती किंवा आवृत्ती नियंत्रण आवश्यक नाही.

स्क्रिप्ट्सची चाचणी करताना हे एक मोठे आव्हान आहे. उदाहरणार्थ, समजा तुम्ही ॲडमिन पेज लेआउटमध्ये नवीन आवश्यक फील्ड जोडले आहे. या बदलानंतर चालवल्या जाणाऱ्या ऑटोमेशन चाचण्या अयशस्वी होतील कारण ते फील्ड भरलेले नाही. Salesforce मध्ये कॉन्फिगरेशन बदल ट्रॅक करते ऑडिट ट्रेल सेट कराचाचणी अयशस्वी होण्याचे कारण लॉगमधून लगेच स्पष्ट होऊ शकत नाही. त्याचप्रमाणे, अनेक महिन्यांपासून वापरलेला चाचणी डेटा जेव्हा प्रमाणीकरण नियम बदलला जातो तेव्हा अचानक नाकारला जाऊ शकतो.

असे कॉन्फिगरेशन बदल अशा परिस्थितीत खूप लवकर आणि वारंवार घडतात जेथे गैर-तांत्रिक प्रशासक सिस्टम व्यवस्थापित करतात. त्यामुळे, चांगल्या सेल्सफोर्स चाचणी योजनेसाठी केवळ कोड बदल केल्यावरच नव्हे, तर कॉन्फिगरेशनमध्ये बदल केल्यावरही चाचण्या चालवणे आवश्यक आहे.

मल्टी-क्लाउड अवलंबित्व लपलेले क्षेत्र तयार करतात ज्यांना चाचणीची आवश्यकता असते

सेल्सफोर्स विविध विभागांमधील जवळच्या परस्परसंवादाच्या आसपास तयार केले गेले. त्यामुळे सेल्स क्लाउडमधील संधी रेकॉर्ड सर्व्हिस क्लाउडमधील नंतरच्या चरणांवर डेटा पास करेल. मार्केटिंग क्लाउडमधील विपणन मोहिमा CRM फील्डमधील बदलांना प्रतिसाद देतील आणि एजंटफोर्स एकाच वेळी क्रियांचे मार्गदर्शन करण्यासाठी अनेक क्लाउडमधील डेटा वापरते.

रेव्हेन्यू लाइफसायकल मॅनेजमेंटमध्ये, संपूर्ण चित्र मिळविण्यासाठी आम्ही सर्व विक्री साधनांचा डेटा वापरतो, जसे की कॉन्फिगर, किंमत, कोट (CPQ), बिलिंग आणि इतर विक्री प्रणाली.

केवळ एकाच क्लाउडमध्ये चाचणी करून, आपण खरोखर वास्तविक प्रणालीची चाचणी करत नाही. सेल्स क्लाउडमध्ये संधी रेकॉर्ड योग्यरित्या प्रदर्शित होत आहे की ते सर्व्हिस क्लाउडमध्ये उत्तम प्रकारे कार्य करते याची हमी देत ​​नाही, जिथे हक्कांची गणना केली जाते. सेल्स क्लाउडमधील फील्डमध्ये एक छोटासा बदल म्हणजे तुमच्या मार्केटिंग मोहिमेने काम करणे थांबवले आहे.

तुमच्या संस्थेत जितके अधिक ढग आहेत (आणि जवळजवळ प्रत्येक मोठी संस्था एकापेक्षा जास्त वापरते), तितके हे परस्परसंवाद अधिक जटिल होतात आणि समस्यांचे निदान करणे अधिक कठीण होते.

म्हणून, या बहु-क्लाउड जगात, वेगळ्या युनिट चाचण्या चुकलेल्या दोष शोधण्याची गुरुकिल्ली म्हणजे एंड-टू-एंड चाचणी.

सँडबॉक्स नेहमी उत्पादनासारखे वागत नाहीत

Salesforce विविध सँडबॉक्स वातावरण ऑफर करते. डेव्हलपर, डेव्हलपर प्रो, आंशिक कॉपी आणि पूर्ण कॉपी, ते लाइव्ह होण्यापूर्वी बदलांची चाचणी आणि प्रमाणीकरण करण्यासाठी. वास्तविक वापरकर्त्यांकडे थेट जाण्यापूर्वी प्रत्येक गोष्टीची सुरक्षितपणे चाचणी करणे हे ध्येय आहे. परंतु सराव मध्ये, चाचणी करणे इतके सोपे नाही.

डेटा व्हॉल्यूममधील फरक हे येथे मुख्य आव्हान आहे. आंशिक सँडबॉक्समध्ये उत्पादनातील डेटाचा फक्त एक छोटासा भाग असतो. त्यामुळे, मोठ्या प्रमाणात डेटा हाताळताना होणारे कार्यप्रदर्शन समस्या किंवा गव्हर्नर मर्यादेचे उल्लंघन तेथे आढळू शकत नाही. सँडबॉक्समधील 200 रेकॉर्डवर चांगले काम करणारा प्रवाह जेव्हा उत्पादनात 50,000 रेकॉर्डपर्यंत पोहोचतो तेव्हा अयशस्वी होऊ शकतो.

दुसरी समस्या म्हणजे इतर सिस्टमशी कनेक्शन. तृतीय-पक्ष एकत्रीकरण किंवा बाह्य डेटा स्रोत अनेकदा सँडबॉक्समध्ये पूर्णपणे सेट केले जात नाहीत. एकीकरण जोडलेले नसल्यामुळे उत्तीर्ण होणारी चाचणी जेव्हा उत्पादनामध्ये वास्तविक कनेक्शन केले जाते तेव्हा अयशस्वी होऊ शकते.

त्याचप्रमाणे, सँडबॉक्समधील वापरकर्ता प्रोफाइल आणि परवानग्या उत्पादनात असलेल्यांपेक्षा कालांतराने भिन्न असू शकतात. सँडबॉक्समध्ये प्रशासक लॉगिनसह चाचणी करताना सर्व काही ठीक कार्य करू शकते, परंतु जेव्हा नियमित वापरकर्ता ते उत्पादनात वापरतो तेव्हा त्रुटी उद्भवू शकते कारण त्यांच्याकडे परवानग्या नसतात.

थोडक्यात, सँडबॉक्समधील परिणाम देखील उत्पादनात समान असतील याची 100% हमी नाही. हे चाचणीतील निष्काळजीपणामुळे नाही, परंतु सँडबॉक्स आणि उत्पादन हे मूलतः दोन भिन्न वातावरण आहेत.

तुमच्या चाचणी रोडमॅपसाठी याचा काय अर्थ होतो

उत्तर स्पष्ट होते: सेल्सफोर्स प्रमाणेच प्रगत अशा प्रकारे चाचणी करा.

सेल्सफोर्स चाचणी नेते अधिक काही करत नाहीत. चालवलेल्या चाचण्यांच्या संख्येसह ते चांगले करत आहेत. त्यांनी काळजीपूर्वक चाचण्या तयार केल्या आहेत जेणेकरुन ते अपयशाचा अंदाज लावू शकतील आणि Salesforce स्टॅकमध्ये समस्या कुठे दिसतील हे त्यांना कळू शकेल.

गुंतागुंतीचे आत्मविश्वासात रूपांतर करा

सेल्सफोर्स हे जगातील सर्वात शक्तिशाली CRM आणि व्यवसाय ऑटोमेशन प्लॅटफॉर्मपैकी एक बनले आहे कारण ते कॉन्फिगर करणे सोपे आहे, बऱ्याच प्रणालींसह समाकलित होते आणि सतत अपडेट केले जात आहे. तथापि, हीच वैशिष्ट्ये ते अधिक जटिल बनवतात. त्यामुळे, सेल्सफोर्स चाचणी हे अनेकांच्या अपेक्षेपेक्षा मोठे आव्हान आहे.

क्वालिटी ॲश्युरन्स (QA) टीमच्या निष्काळजीपणामुळे चाचण्या अयशस्वी होत नाहीत. उलट, प्लॅटफॉर्म वाढल्यामुळे आमच्या चाचणी पद्धती बदलल्या नाहीत. रिलीझ तुमच्या सोयीनुसार होत नाहीत, तर सेल्सफोर्सच्या कॅलेंडरनुसार होतात. तैनाती दरम्यान कॉन्फिगरेशन बदलतात. Shadow DOM नियमित निवडकर्त्यांना UI शोधणे कठीण करते. सँडबॉक्स अनेक प्रकारे उत्पादनापेक्षा भिन्न आहेत. हे सर्व अंदाज लावता येण्याजोगे अपयश आहेत आणि योग्य नियोजनाने आपण या अंदाज लावल्या जाणाऱ्या समस्यांवर मात करू शकतो.

सेल्सफोर्स चाचणीला तैनातीपूर्वी पूर्ण करावयाच्या केवळ चेक-बॉक्सऐवजी सतत प्रक्रिया मानणारे संघच दोष शोधू शकतात. ग्राहक समर्थनापर्यंत तक्रारी म्हणून पोहोचण्यापूर्वी CI पाइपलाइनमधील समस्या लवकर ओळखणे ही मुख्य गोष्ट आहे. सेल्सफोर्स चाचणीमधील तुमचे यश येथेच आहे.