टेस्ट कंपनी डेटा: टीम के लिए एक व्यावहारिक गाइड

टेस्ट कंपनी डेटा किसी मनगढ़ंत कारोबारी इकाई का पूरा लिखित रिकॉर्ड है। इसमें कंपनी का नाम, कानूनी स्वरूप, पंजीकरण नंबर, टैक्स नंबर और VAT नंबर, पंजीकृत कार्यालय, संपर्क टेलीफ़ोन नंबर और कुछ छोटे फ़ील्ड जोड़कर ऐसा रिकॉर्ड तैयार होता है जो देखने में एक साधारण व्यापारिक कंपनी जैसा लगे, पर किसी असली कंपनी का वर्णन न करे।

यह लेख बताता है कि ऐसे रिकॉर्ड का असल मकसद क्या है, किसी असली कंपनी के विवरण उधार लेना कानून और इंजीनियरिंग दोनों में बुरा सौदा क्यों है, बिज़नेस के किन हिस्सों को इसकी ज़रूरत पड़ती है, और इस साइट का जनरेटर अपने नतीजे के बारे में क्या गारंटी देता है और क्या नहीं।

टेस्ट कंपनी डेटा असल में क्या है

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

सुसंगति ही एक काम के लायक रिकॉर्ड और बेतरतीब स्ट्रिंग के ढेर के बीच फ़र्क़ करती है। पंजीकरण नंबर उसी देश के रजिस्टर का होता है जिसका पता रिकॉर्ड में दर्ज है, VAT नंबर पर उसी देश का प्रीफ़िक्स लगा होता है, कानूनी स्वरूप वही होता है जिसे वह अधिकार क्षेत्र सचमुच मान्यता देता है, और टेलीफ़ोन नंबर पर सही कॉलिंग कोड होता है। फ़ील्ड दर फ़ील्ड जोड़ा गया रिकॉर्ड आम तौर पर ठीक इसी जगह नाकाम होता है, क्योंकि हर फ़ील्ड को अकेले आंका गया था।

स्रोत ही टेस्ट रिकॉर्ड को असली रिकॉर्ड से अलग करता है। इसमें कुछ भी किसी कंपनी से कॉपी नहीं किया गया, और इसमें कुछ भी किसी कंपनी का नहीं है। इसका आकार कारोबार जैसा है ताकि कोई सिस्टम इसे प्रोसेस कर सके, और टेस्ट के बाहर इसका कोई अस्तित्व नहीं है।

टीम को ऐसे बिज़नेस रिकॉर्ड की ज़रूरत कब पड़ती है?

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

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

किसी असली कंपनी के विवरण इस्तेमाल करना गलत क्यों है?

क्योंकि किसी असली कंपनी का पंजीकरण नंबर, टैक्स नंबर और पदाधिकारी किसी और के व्यक्तिगत और व्यापारिक तथ्य हैं, और निचले एनवायरनमेंट वही जगहें होती हैं जहां सुरक्षा नियंत्रण आम तौर पर सबसे कमजोर रहते हैं।

इससे दो तरह की नाकामी निकलती हैं। पहली कानूनी और प्रतिष्ठा से जुड़ी है। अपने आप को किसी और कारोबार के रूप में पेश करना भ्रामक प्रस्तुति है, और डेटा संरक्षण नियमों के तहत किसी एकल व्यापारी का पंजीकरण विवरण संपर्क नाम के साथ व्यक्तिगत डेटा भी बन सकता है। उन तथ्यों को डेवलपमेंट एनवायरनमेंट में ले जाना उस डेटा का नया उपयोग है जिसकी किसी ने अनुमति नहीं दी थी। दूसरी परिचालन संबंधी है: वह कॉपी बैकअप में, क्वेरी लॉग में, टिकट के साथ चिपके स्क्रीनशॉट में और उन सबके लैपटॉप में बनी रहती है जिन्होंने कभी वह डेटाबेस रिस्टोर किया। नतीजा यह होता है कि संस्था के पास एक ही कंपनी के विवरण की प्रतियां पहले से कहीं ज़्यादा हो जाती हैं, और वे ऐसी जगहों पर होती हैं जहां कोई ऑडिट नहीं होता।

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

पूरे कंपनी रिकॉर्ड में क्या क्या होता है?

इस साइट पर टेस्ट कंपनी डेटा जनरेटर पूरी इकाई एक ही चरण में बनाता है, फ़ील्ड दर फ़ील्ड नहीं। एक रिकॉर्ड में चार समूह के फ़ील्ड होते हैं।

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

नतीजे पर भरोसा करने से पहले दो गुण समझ लेना ज़रूरी है। पहला आंतरिक सुसंगति है, जैसा ऊपर बताया गया। दूसरा पुनरुत्पादनक्षमता है: नतीजा एक पहचान कुंजी से चलता है, और वही कुंजी उसी देश के साथ हर बार ठीक वही कंपनी देती है। पुनरुत्पादनक्षमता ही बनाए गए रिकॉर्ड को ऑटोमेटेड टेस्ट के भीतर उपयोगी बनाती है, न कि सिर्फ़ मैनुअल वॉकथ्रू में। फ़ील्ड की सुसंगति का सवाल असल में जनरेशन के क्रम का सवाल है, और कानूनी स्वरूप वाला लेख बताता है कि देश का फ़ैसला बाकी सब से पहले क्यों लेना पड़ता है।

बनाए गए कंपनी डेटा को असली जैसा दिखना ज़रूरी है?

उसे साधारण दिखना चाहिए, जो कमज़ोर शर्त है — और यह फ़र्क़ मायने रखता है।

जानबूझकर नकली दिखने वाला रिकॉर्ड पढ़ने वाले के लिए खारिज करना आसान बनाता है, पर किसी सत्यापन नियम के लिए भी आसान बनाता है कि वह गलत वजह से उसे अस्वीकार कर दे। अजीब दिखने वाला रिकॉर्ड गलत चीज़ टेस्ट करता है: अगर हर बनाया गया कंपनी नाम एक ही अक्षर का हो, या हर सड़क पंक्ति वही प्लेसहोल्डर वाक्यांश हो, तो लेआउट कभी दबाव में नहीं आता और सत्यापन कभी चालू ही नहीं होता। बनाए गए रिकॉर्ड तब काम आते हैं जब वे उसी आकार में उतरते हैं जिस आकार में सिस्टम को आगे असली सबमिशन मिलेंगे — लंबे कानूनी नाम, एक्सेंट वाले अक्षर, पंजीकृत नाम से अलग ट्रेडिंग नाम, और ऐसी इकाइयां जिनके पास वैध रूप से कोई VAT नंबर नहीं होता।

साधारण होना और दुनिया में मान्य होना एक बात नहीं है। सही आकार वाला काल्पनिक पंजीकरण नंबर भी कहीं पंजीकृत नहीं होता। वह प्रारूप जांच पास कर लेगा और उसी पल नाकाम हो जाएगा जब कोई प्रक्रिया उसके पीछे के रजिस्टर से पूछताछ करेगी। यह खामी नहीं, विशेषता है: काल्पनिक कंपनी डेटा की सीमाएं ही वह चीज़ हैं जो टेस्ट रिकॉर्ड को असली रिकॉर्ड समझे जाने से रोकती हैं।

डेवलपर्स के लिए: रिकॉर्ड का डिज़ाइन

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

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

फिक्स्चर के साथ जाने वाला नोट भी डिज़ाइन का हिस्सा है। फ़ाइल में और टूल जो भी एक्सपोर्ट बनाए उसमें साफ़ लिखें कि ये कंपनियां टेस्टिंग के लिए गढ़ी गई हैं, कि इनसे किसी असली कारोबार का वर्णन नहीं होता, और इन रिकॉर्ड का उपयोग खाते खोलने, लाइसेंस लेने, असली इनवॉइस जारी करने या किसी असली पक्षकार की जगह लेने के लिए नहीं किया जाना चाहिए।

अगले कदम

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