इस पेज पर
420 संख्या दो परस्पर विरोधी कारणों से सही हो सकती है. इस उदाहरण में दो एजेंट एक ही संपर्क सेगमेंट लौटाते हैं और दोनों 420 ग्राहक गिनते हैं. एक ने स्वीकृत स्टोर ऑडियंस इस्तेमाल की और सहमति जांची. दूसरे ने किसी और वर्कस्पेस का पुराना एक्सपोर्ट कॉपी किया और संयोग से वही संख्या पाई.
केवल परिणाम देखने वाला स्कोर दोनों को पूरे अंक देगा. यह गलत मूल्यांकन है.
एजेंट वातावरण में सत्यापन पर चर्चा अंतिम आउटपुट को वहां तक पहुंचने के रास्ते से अलग करती है. उसके स्प्रेडशीट उदाहरण में सही संख्या काम का केवल एक भाग है. फ़ॉर्मूला, स्रोत संदर्भ और आवश्यक फ़ॉर्मैट भी मायने रखते हैं. इंटीग्रेशन में अंतर और तीखा है: परिणाम कहां से आया, इसी से तय हो सकता है कि उसका उपयोग अनुमत था भी या नहीं.
अंतिम मान अपना स्रोत सिद्ध नहीं कर सकता
मान लें एजेंट स्टोर के ग्राहक ऑब्जेक्ट से मार्केटिंग सिस्टम के लिए फ़ील्ड मैप सुझाता है. वह email को ईमेल, firstName को पहला नाम और सहमति फ़ील्ड को डेस्टिनेशन की मार्केटिंग स्थिति से जोड़ता है. प्रीव्यू ठीक दिखता है.
चुनाव के लिए उसने क्या पढ़ा? वर्तमान स्कीमा, पुराना नमूना या दूसरे अकाउंट का दस्तावेज़? क्या उसने सहमति फ़ील्ड का अर्थ देखा या नाम से अनुमान लगाया? क्या null को “सब्सक्राइब नहीं” समझा या “अज्ञात”?
हर उत्तर तय करता है कि वही अंतिम मैप कितना भरोसेमंद है. मैप आउटपुट है. प्रमाण की कड़ी उसका उपयोग करने का तर्क है.
इस कड़ी में निर्णय के समय उपलब्ध हर स्रोत का संस्करण दर्ज होना चाहिए. बाद में सुधरे स्कीमा का स्क्रीनशॉट कल सुझाए गए मैप को नहीं समझाता. संबंधित स्कीमा या दस्तावेज़ का संस्करण निर्णय के साथ रखें, फिर उस संस्करण और स्वीकृत नियम का संबंध बचाएं. उद्देश्य निर्णय फिर से समझ सकना है, एजेंट ने देखे हर पेज को सहेजना नहीं.
इसीलिए टूल ट्रेस आत्मविश्वासी व्याख्या से अधिक महत्वपूर्ण हो सकता है. ट्रेस एजेंट के ठोस कॉल और पहचानकर्ता दर्ज करता है. लिखी हुई व्याख्या उपयोगी है, पर वह यह सिद्ध नहीं करती कि स्रोत देखा गया था. इंटीग्रेशन में प्रमाण को स्रोत ऑब्जेक्ट, डेस्टिनेशन अनुबंध और डेटा ले जाने वाले विशिष्ट नियम की ओर ले जाना चाहिए.
बिज़नेस टूल जोड़ने की गाइड फ़ील्ड स्वामित्व से शुरू होती है, क्योंकि दोनों ओर के नाम शायद ही अधिकार तय करते हैं. प्रक्रिया जांच यह पूछती है कि लिखने का ड्राफ़्ट बनाने से पहले एजेंट ने उस स्वामित्व निर्णय को देखा भी था या नहीं.
अनुमत रास्ता काम में ही लिखें
अच्छे परीक्षण के दो भाग हैं. पहले बताएं डेस्टिनेशन में क्या होना चाहिए. फिर बताएं वहां जाते हुए किन प्रमाणों और कार्यों की अनुमति है.
उदाहरण के सेगमेंट में अपेक्षित आउटपुट 420 संपर्क हो सकते हैं. स्वीकृत रास्ते में स्टोर के दायरे की क्वेरी, वर्तमान सहमति मैपिंग और बाहर रखे रिकॉर्ड दिखाने वाला प्रीव्यू भी आवश्यक हो सकते हैं. वह दूसरे वर्कस्पेस का पढ़ना और सीधे कैम्पेन भेजना मना कर सकता है.
इससे सत्यापक विशिष्ट बनता है. वह दूसरे वर्कस्पेस का पहचानकर्ता यांत्रिक ढंग से अस्वीकार कर सकता है. सक्रिय करने से पहले प्रीव्यू कॉल हुआ था या नहीं, जांच सकता है. आउटपुट का डेटा स्रोत ट्रेस के स्रोत से मिल सकता है. ये नियम हैं, मॉडल की राय नहीं.
एक शेष सवाल पर निर्णय चाहिए हो सकता है: क्या चुना हुआ सहमति फ़ील्ड वास्तव में इस कैम्पेन की अनुमति देता था? यहां व्यक्ति या सीमित निर्णय मॉडल को फ़ील्ड की परिभाषा और इच्छित उपयोग देखना चाहिए. नियम और निर्णय के काम अलग हैं.
इससे परीक्षण उपयोगी विफलता संदेश देता है. “गलत उत्तर” टीम को अनुमान लगाने देता है. “संख्या सही थी, लेकिन ऑडियंस दूसरे वर्कस्पेस से पढ़ी गई” डेटा सीमा की विफलता बताता है. “मैप सही था, लेकिन सहमति की परिभाषा उपलब्ध नहीं थी” प्रमाण की कमी बताता है. सत्यापक विफल शर्त और संबंधित ट्रेस प्रविष्टि दिखाए, ताकि सुधार अंतिम शब्दों को चमकाने के बजाय रास्ता बदले.
ट्रेस क्या साबित करता है?
-
स्वीकृत स्रोत और आवश्यक जांच
रास्ता स्वीकार करें
परिणाम के पास काम के लिए ज़रूरी प्रमाण है.
-
दूसरे वर्कस्पेस का स्रोत
रास्ता अस्वीकार करें
मिलती संख्या उस पढ़ने की अनुमति नहीं देती.
-
अनिवार्य प्रमाण गायब
समीक्षा तक रोकें
केवल आउटपुट यह नहीं बताता कि वह कैसे निकला.
ट्रेस को औपचारिक रस्म न बनाएं
उचित आपत्ति है: “एजेंट आवश्यक कॉल कर सकता है और फिर भी उन्हें अनदेखा कर सकता है.” सही. कॉल सूची साबित करती है कि कॉल हुआ. वह यह नहीं साबित करती कि लौटे प्रमाण ने निर्णय को प्रभावित किया.
इसे जांचने का एक तरीका प्रमाण बदलना है. बाकी लगभग समान दो रिकॉर्ड दें जिनकी सहमति स्थिति अलग हो. एजेंट दोनों में वही मैपिंग और व्याख्या दे तो उसका कथित स्रोत परामर्श दिखावा हो सकता है. दूसरा तरीका आवश्यक स्रोत हटाकर एजेंट से रुकने की अपेक्षा करना है. स्मृति से खाली जगह भरने वाला एजेंट अनुमत रास्ते पर नहीं चला.
परीक्षण उदाहरण बनाने में अतिरिक्त काम लगता है. किसी को अनुमत स्रोत, अपेक्षित अंतर और निषिद्ध छोटे रास्ते तय करने होंगे. सामान्य “उत्तर अच्छा दिखा?” स्कोर बनाना सस्ता है, पर उससे कम सीख मिलती है.
रिवर्स ETL मैपिंग को बार-बार डेटा स्थानांतरण में बदलता है. मैपिंग स्वीकृत होने के बाद सामान्य कोड हर पंक्ति पर एजेंट से प्रमाण दुबारा पूछे बिना उसे लागू कर सकता है. रास्ते की जांच नियम बनाने या बदलने वाले निर्णयों पर, और बदले अनुबंध से फिर सवाल उठने पर होनी चाहिए.
गलत अकाउंट के रास्ते मिला सही उत्तर मामूली चूक नहीं. वह अलग काम है.
अक्सर पूछे जाने वाले प्रश्न
अंतिम उत्तर सही हो तो रास्ता क्यों देखें?
एजेंट ने अनधिकृत डेटा उपयोग किया हो, अनिवार्य जांच छोड़ी हो या संयोग से सही मान पाया हो. केवल आउटपुट यह साबित नहीं करता कि रास्ता सुरक्षित या दोहराने योग्य था.
क्या हर बीच के कार्य की इंसान को समीक्षा करनी चाहिए?
नहीं. टूल कॉल दर्ज करें और निषिद्ध कार्यों के लिए निर्धारक नियम लागू करें. गंभीर असर वाले या अस्पष्ट चरण देखें और प्रतिनिधि ट्रेस जांचें.
टीम इसे कैसे जांच सकती है?
अपेक्षित अंतिम स्थिति के साथ अनुमत प्रमाण स्रोत और अनिवार्य जांच तय करें. ऐसे मामले फिर चलाएं जहां छोटा रास्ता वही उत्तर दे सकता हो और देखें कि सत्यापक उसे अस्वीकार करता है या नहीं.