टेस्ट पहचान डेटा क्या है और किसे इसकी ज़रूरत होती है

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

यह गाइड बताती है कि ऐसे रिकॉर्ड कहां से आते हैं, किन हालात में इनकी सचमुच ज़रूरत पड़ती है, प्रोडक्शन डेटा क्यों बुरा विकल्प है, और इस साइट का जनरेटर नतीजे के बारे में क्या गारंटी देता है और क्या नहीं।

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

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

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

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

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

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

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

प्रोडक्शन डेटा गलत विकल्प क्यों है

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

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

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

बनाए गए रिकॉर्ड में क्या होता है

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

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

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

क्या बनाए गए रिकॉर्ड असली जैसे दिखने चाहिए?

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

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

यही फ़ील्ड जोड़ियां कंसिस्टेंसी जांच में बार-बार क्यों फेल होती हैं

हाथ से टेस्ट रिकॉर्ड बनाने वाली टीमों को बार-बार वही खामियां मिलती हैं, और वे लगभग हमेशा मान की नहीं बल्कि रिश्ते की खामियां होती हैं। सड़क विश्वसनीय है, शहर विश्वसनीय है, पोस्टल कोड विश्वसनीय है — और तीनों अलग-अलग देशों के हैं।

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

डेवलपर्स के लिए: पहचान रिकॉर्ड किन चीज़ों से बनता है

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

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

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

अगले कदम

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