रैंडम शब्द सुनकर ज्यादातर लोग एक ही चीज सोचते हैं — हर फ़ील्ड में कुछ भी भर दो। यह ठीक वही गलती है जिसकी वजह से बहुत से टेस्ट डेटासेट बेकार हो जाते हैं। एक पता अकेला फ़ील्ड नहीं है। वह ऐसी संरचना है जिसमें देश, प्रशासनिक क्षेत्र, इलाका, डाक कोड और फ़ोन कोड एक-दूसरे से बंधे होते हैं। जब आप हर हिस्से को अलग-अलग बेतरतीब ढंग से भरते हैं, तो हर हिस्सा अपने आप में ठीक होता है और पूरा रिकॉर्ड पूरी तरह असंभव होता है।
यह लेख बताता है कि रैंडमपन कहां लगाना चाहिए और कहां नहीं, क्यों एक ही बीज से बार-बार वही रिकॉर्ड बनना बड़ी विविधता से ज्यादा कीमती है, बैच निर्यात करते समय कौन सी चीजें टूटती हैं, और वह सीमा कहां है जिसके आगे कोई रैंडम रिकॉर्ड उपयोगी नहीं रहता।
रैंडम और असंगत दो अलग समस्याएं क्यों हैं?
रैंडम एक साधन है, और असंगत एक परिणाम है। इन्हें एक मान लेना ही सबसे बड़ी गलती है। रैंडम का मतलब है कि आप उन हिस्सों में विविधता डाल रहे हैं जिनके बीच कोई बंधन नहीं है। असंगत का मतलब है कि आपने वह विविधता उन हिस्सों में भी डाल दी जिनके बीच बंधन था। पहला स्थिति में फायदा है, दूसरा स्थिति में वह डेटा बेकार है।
जिन हिस्सों में बंधन नहीं है, वहां रैंडमपन बेझिझक लगाएं। भवन संख्या, इमारत का नाम, सड़क के नाम की वर्तनी की भिन्नताएं, और एक ही बैच के भीतर रिकॉर्ड का क्रम — ये सब ऐसी चीजें हैं जिन्हें बदलने से कोई संबंध नहीं टूटता। इनमें विविधता डालने से आपके सिस्टम की वास्तविक सहनशीलता परखी जाती है, क्योंकि असली दुनिया में यही विविधता रोज आती है।
जिन हिस्सों में बंधन है, वहां रैंडमपन नहीं लगाना चाहिए। डाक कोड को उसके क्षेत्र से निकाला जाना चाहिए, चुना नहीं जाना चाहिए। प्रशासनिक क्षेत्र को उस इलाके से निकाला जाना चाहिए जिसमें वह आता है। फ़ोन का क्षेत्रीय उपक्रम उस देश और क्षेत्र से निकलना चाहिए। इन तीनों में से किसी भी एक को बेतरतीब ढंग से भरने पर ऐसा रिकॉर्ड बनता है जो किसी भी देश में संभव ही नहीं।
सबसे आम गलती यह है कि जनरेटर चार अलग-अलग सूचियों से एक-एक मान उठा लेता है — एक से देश, एक से क्षेत्र, एक से शहर, एक से डाक कोड। चारों मान वैध होते हैं, पर उनका मेल खाना कोई गारंटी नहीं। इसका समाधान जनरेटर की बनावट में है, उसके आउटपुट में नहीं। आपको पहले एक जगह तय करनी चाहिए, फिर उस जगह के सारे फ़ील्ड उससे निकालने चाहिए।
इसका सबसे साफ क्रम यह है। पहले देश चुनें, क्योंकि वह हर बाकी फ़ील्ड का ढांचा तय करता है। फिर उस देश के भीतर प्रशासनिक क्षेत्र चुनें। फिर उस क्षेत्र के भीतर इलाका या शहर चुनें। अब डाक कोड और फ़ोन के उपक्रम को इस चुनी हुई जगह से निकालें, बेतरतीब ढंग से नहीं। जब आपका जनरेटर इस क्रम में चलता है, तो आपका हर रिकॉर्ड अंदर से सुसंगत रहता है, चाहे उसके भवन संख्या या सड़क का नाम कितना भी बेतरतीब हो।
क्या रैंडम होना चाहिए और क्या तय?
फ़ील्डों को तीन श्रेणियों में बांटना इस पूरी समस्या को साफ कर देता है। पहली श्रेणी वे हैं जो हर बार बदलने चाहिए — सड़क का नाम उस सीमित सूची के भीतर जो उस इलाके में मान्य है, भवन संख्या, फ्लैट या इकाई संख्या, कंपनी का नाम, प्राप्तकर्ता का नाम, और निर्यात का क्रम। इनमें विविधता डालने से आपके सिस्टम की सहनशीलता परखी जाती है और कोई संबंध नहीं टूटता।
दूसरी श्रेणी वे हैं जो कभी नहीं बदलने चाहिए, क्योंकि इनका बाकी फ़ील्डों से सीधा बंधन है। प्रशासनिक क्षेत्र उस इलाके से मेल खाना चाहिए जिसमें वह रखा गया है। डाक कोड उस प्रशासनिक क्षेत्र से मेल खाना चाहिए। फ़ोन का क्षेत्रीय उपक्रम उसी क्षेत्र का होना चाहिए। देश का मान उन सब फ़ील्डों के प्रारूप से मेल खाना चाहिए जो उसके अंदर बने हैं। इनमें एक भी चीज बेतरतीब हुई, और पूरा रिकॉर्ड झूठा बन गया।
तीसरी श्रेणी सबसे दिलचस्प है। इसमें वे फ़ील्ड आते हैं जो कुछ परीक्षणों में रैंडम होने चाहिए और कुछ में जमे हुए। जन्म तिथि इसका सबसे अच्छा उदाहरण है। जब आप आयु संबंधी नियम परख रहे हों, तो उसे बदलना जरूरी है। जब आप किसी और चीज की जांच कर रहे हों, तो उसे जमे रहने देना चाहिए, वरना आपका परीक्षण कभी दो बार एक जैसा नहीं चलेगा।
इसी वजह से ऐसा जनरेटर ज्यादा उपयोगी होता है जिसमें आप एक-एक फ़ील्ड को अलग से तय कर सकें। जिस जनरेटर में केवल एक ही बटन हो और वह सब कुछ या तो बेतरतीब कर दे या सब कुछ जमा दे, वह आधे परीक्षणों के लिए बेकार है। जब आप किसी एक फ़ील्ड को पिन कर सकते हैं और बाकी को स्वतंत्र छोड़ सकते हैं, तब आप वह परीक्षण बना पाते हैं जो असल में किसी एक व्यवहार को परखता है।
विविधता से ज्यादा दोहराव योग्यता क्यों जरूरी है
एक ही बीज और एक ही देश देने पर हमेशा वही रिकॉर्ड बनना चाहिए। यह शर्त सुनने में उबाऊ लगती है और असल में सबसे कीमती है। परीक्षण अपनी अपेक्षा पर टिकता है। जब आप लिखते हैं कि इस इनपुट पर यह नतीजा आना चाहिए, तो आपका दावा तभी अर्थ रखता है जब वह इनपुट हर बार वही हो। अगर जनरेटर हर बार कुछ नया बनाता है, तो आपका परीक्षण अपेक्षा की जांच नहीं कर रहा, वह केवल यह देख रहा है कि कोई चीज चलती है या नहीं।
असली फायदा तब दिखता है जब कुछ टूटता है। असफल परीक्षण को दोबारा चलाना तभी संभव है जब आप वही डेटा फिर से बना सकें। जिस रिकॉर्ड के पीछे कोई बीज दर्ज नहीं, वह एक बार गुजर जाने के बाद लौटकर नहीं आता। फिर आपके पास केवल यह विकल्प बचता है कि आप दोष को देखकर हाथ से उसे दोबारा बनाएं, जो कभी ठीक वैसा नहीं बनेगा।
इसलिए बीज को प्रति परीक्षण नहीं, प्रति फिक्स्चर रखें। यह बारीक पर बड़ा फर्क है। अगर हर परीक्षण का अपना बीज होगा, तो आपके पास बहुत से अलग-अलग रिकॉर्ड होंगे जिनमें से किसी का भी कोई दूसरा परीक्षण उपयोग नहीं कर सकता। अगर हर फिक्स्चर का एक स्थिर बीज होगा, तो कई परीक्षण एक ही रिकॉर्ड साझा कर सकेंगे और वे एक ही असली वस्तु के बारे में बात कर रहे होंगे।
इसका एक और साफ फायदा है। जब किसी फिक्स्चर का डेटा बदलता है, तो वह बदलाव साफ दिखता है, क्योंकि वह अचानक होता है और एक तय जगह पर होता है। जब डेटा हर बार अपने आप बदलता है, तो बदलाव कोई सूचना नहीं देता। और कोई बदलाव जो सूचना नहीं देता, वह जल्दी ही वैसा ही हो जाता है जैसा कोई बदलाव हुआ ही न हो।
बैच निर्यात आपके टेस्ट सुइट को कैसे बदलता है
जब आप एक-एक रिकॉर्ड के बजाय एक पूरा बैच निर्यात करते हैं, तो कुछ नई चीजें जरूरी हो जाती हैं। पहली यह कि फ़ाइल में एक पंक्ति में एक पता हो, और स्तंभों के नाम स्थिर हों। स्थिर स्तंभ नाम होने से आप ऐसे परीक्षण लिख सकते हैं जो डेटा से चलते हैं और जिनमें हर पंक्ति अपने आप एक मामला बन जाती है। यह सबसे कम मेहनत में सबसे ज्यादा मामले परखने का तरीका है।
दूसरी जरूरत यह है कि हर पंक्ति के साथ यह दर्ज हो कि वह बनाई गई है। अगर केवल फ़ाइल का नाम या किसी बाहरी दस्तावेज में यह लिखा हो, तो वह जानकारी अलग हो जाएगी और जल्दी ही किसी को याद नहीं रहेगी। बेहतर यह है कि फ़ाइल में ही एक अलग स्तंभ हो जिसमें यह साफ लिखा हो कि यह रिकॉर्ड काल्पनिक है। यह छोटी-सी आदत बाद में बहुत बड़ी गलतियों से बचाती है।
तीसरी बात यह है कि बड़े बैच वे समस्याएं दिखाते हैं जो छोटे नमूने कभी नहीं दिखाते। अगर आप केवल बीस पंक्तियां बनाएंगे, तो आपको यह कभी पता नहीं चलेगा कि डाक कोड कुछ ही मानों में सिमट जाते हैं, या यह कि शहरों की सूची बीस पंक्तियों के बाद दोहराने लगती है। ये समस्याएं छोटे नमूने में छिपी रहती हैं और बड़े डेटा में तब दिखती हैं जब उन्हें ठीक करना महंगा हो चुका होता है।
चौथी बात यह है कि बैच को केवल परीक्षण के लिए नहीं, भंडार भरने के लिए भी उपयोग किया जाता है। जब आप इस डेटा से अपना परीक्षण वातावरण भरते हैं, तो आप बाद में यह देख सकते हैं कि किसी बदलाव के बाद गिनती वैसी ही रही या नहीं, और वितरण वैसा ही रहा या नहीं। यह तुलना तभी संभव है जब डेटा दोहराव योग्य हो और उसका बीज दर्ज हो।
देश मिलाते समय सबसे पहले क्या टूटता है
सबसे पहले डाक क्षेत्र और प्रशासनिक क्षेत्र का मेल टूटता है। यह वह गलती है जिसे कोई भी एकल फ़ील्ड जांच कभी नहीं पकड़ सकती, क्योंकि दोनों मान अपने आप में पूरी तरह वैध होते हैं। डाक कोड वैध है, क्षेत्र का नाम वैध है, पर वे दो अलग देशों या अलग प्रांतों के हैं। केवल ऐसी जांच इसे पकड़ सकती है जो दोनों के बंधन को जानती हो।
दूसरे नंबर पर फ़ोन और पते का देश टूटता है। जब एक बैच में कई देश मिल जाते हैं, तो फ़ोन का क्षेत्रीय उपक्रम अक्सर अपने डिफ़ॉल्ट पर बना रह जाता है। नतीजा यह होता है कि पता एक देश का है और फ़ोन का कोड दूसरे देश का। यह गलती बहुमत के बहाव में छिप जाती है, क्योंकि ज्यादातर पंक्तियों में सब कुछ ठीक होता है और केवल थोड़ी पंक्तियां टूटी होती हैं।
तीसरा अंतर फ़ील्डों के समूह का है। जिन देशों में डाक कोड होता ही नहीं, उनके लिए बनाई गई पंक्तियों में वह फ़ील्ड खाली रहेगा, जबकि आपके परीक्षण की अपेक्षा होगी कि वहां पांच अंक हों। यह ऐसी विफलता है जो आपके सिस्टम में नहीं, आपके डेटा में है। इसे पहचानना जरूरी है, वरना आप ऐसी जगह सुधार करते रहेंगे जहां कोई गलती ही नहीं थी।
चौथा अंतर उन देशों से आता है जिनमें राज्य जैसा फ़ील्ड होता ही नहीं, पर आपका फ़ॉर्म उसे हर जगह अनिवार्य मानता है। ऐसी स्थिति में डेटा में ऐसे मान भर जाते हैं जो वास्तव में कुछ नहीं हैं, और बाद में कोई भी रिपोर्ट उन पर भरोसा नहीं कर सकती। यह समस्या डेटा में दिखती है और उसका मूल कारण फ़ॉर्म के नियम में होता है।
पांचवां, मिले हुए देशों के बैच को एक ही क्रम में लगाने पर नतीजा उलझा हुआ दिखता है। यह अक्सर डेटा की गलती नहीं, बल्कि तुलना के नियम की गलती होती है — किसी भाषा के अक्षरों का क्रम दूसरी भाषा में दूसरा होता है। इसे डेटा में ठीक करने की कोशिश मत करें, इसे वहीं ठीक करें जहां वह पैदा हुआ था, यानी दिखाने की परत पर।
क्या रैंडम पते लोड टेस्टिंग के लिए उपयोगी हैं?
हां, पर एक साफ शर्त के साथ। जनरेटर को डेटा बनाने में उतना समय नहीं लेना चाहिए कि वह उस सिस्टम से ज्यादा भारी पड़ जाए जिसे आप परख रहे हैं। अगर आपके भार परीक्षण के दौरान ज्यादातर समय डेटा बनाने में जाता है, तो आप यह नहीं जान पाएंगे कि आपकी सेवा कितनी टिकाऊ है, क्योंकि अड़चन कहीं और है।
इसका सीधा हल यह है कि डेटा पहले से बनाकर रख लिया जाए। एक बार बड़े पैमाने पर पंक्तियां बनाएं, उन्हें भंडार में रखें, और फिर भार परीक्षण के दौरान उन्हें बार-बार पढ़ें। इससे भार का असली माप आपकी सेवा पर पड़ता है, न कि आपके जनरेटर पर। जो भार परीक्षण जनरेटर को हर पंक्ति पर बुलाता है, वह असल में अपने जनरेटर की गति माप रहा होता है।
इसके उलट एक और तरीका है जिसे फ़ज़िंग कहा जाता है, और उसका तर्क उलटा है। वहां आप पहले ऐसे रिकॉर्ड बनाते हैं जो पूरी तरह वैध हैं, और फिर उनमें जानबूझकर कुछ हिस्से तोड़ते हैं। एक फ़ील्ड को बीच से काटें, उसमें ऐसा अक्षर डालें जो उस व्यवस्था में कभी नहीं आता, या डाक कोड को किसी और देश का मान बना दें। इससे यह पता चलता है कि आपका सिस्टम किस तरह का टूटा हुआ डेटा सह लेता है और किस पर रुक जाता है।
जो बात अक्सर छूट जाती है, वह यह है कि इन टूटे हुए मामलों की सूची भी जनरेटर की सेटिंग के साथ दर्ज होनी चाहिए। अगर आपने हर बार नए तरीके से डेटा तोड़ा और कहीं यह नहीं लिखा कि क्या-क्या तोड़ा गया था, तो अगली बार वही परीक्षण दोहराना संभव नहीं होगा। फ़ज़िंग का लाभ तभी मिलता है जब टूटे हुए मामलों की सूची भी एक ऐसी चीज बने जिसे संभाला और दोहराया जा सके।
रैंडम रिकॉर्ड क्या नहीं हो सकता
वह कोई असली पता नहीं है। भले ही उसमें एक इमारत का नाम, एक सड़क और एक डाक कोड हो, वह किसी इमारत की ओर इशारा नहीं करता और किसी व्यक्ति से जुड़ा नहीं है। कोई डिलीवरी सेवा उसे स्वीकार नहीं करेगी और वह निवास का प्रमाण नहीं बन सकता। ये सीमाएं केवल शिष्टाचार नहीं हैं, ये इस डेटा की परिभाषा का हिस्सा हैं।
यह बात केवल साथ में लिखे गए दस्तावेज में नहीं, बल्कि डेटासेट के भीतर ही दर्ज होनी चाहिए। जिस फ़ाइल को कोई उठाए, उसे उसी फ़ाइल से पता चल जाना चाहिए कि यह क्या है और क्या नहीं। जो सीमा केवल किसी दूसरे दस्तावेज में लिखी हो, वह जल्दी ही उस फ़ाइल से अलग हो जाती है और फिर किसी को याद नहीं रहती।
एक और बात साफ करना जरूरी है। रैंडम करना और गुमनाम करना दो अलग काम हैं। किसी असली रिकॉर्ड से नाम और पता उठाकर उन्हें आपस में मिला देना रैंडम डेटा नहीं बनाता। वह ऐसा डेटा बनाता है जो असली लोगों के असली टुकड़ों से बना है, और उस पर वे सारे नियम लागू रहते हैं जो असली डेटा पर लागू होते हैं। यह भ्रम महंगा पड़ता है, क्योंकि ऐसा डेटा देखने में काल्पनिक लगता है पर असल में नहीं है।
जो भी रिकॉर्ड आप बनाएं, वह तीन शर्तें पूरी करना चाहिए। उसे भंडार में रखा जा सके, उसे किसी परीक्षण के फिक्स्चर के रूप में जमा किया जा सके, और छह महीने बाद उसे ठीक उसी रूप में फिर से बनाया जा सके। तीसरी शर्त सबसे कठिन है और सबसे जरूरी, क्योंकि वही तय करती है कि आपके पास परीक्षण का एक स्थायी आधार है या केवल एक बार का प्रयोग।
शुरुआत करने के लिए पता टूल का उपयोग करें और उसके साथ देश के नियम जोड़ें, क्योंकि रैंडमपन का असली दबाव देश बदलने पर ही दिखता है। इसके साथ सत्यापन के नियम और कंपनी के रिकॉर्ड भी जोड़ें, ताकि आपका बैच उसी जटिलता को दिखाए जो असली प्रणालियों में होती है।