पहचान फ़ील्ड सुसंगतता: बुरे डेटा पर टेस्ट क्यों पास हो जाते हैं

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

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

अलग-अलग सही फ़ील्ड मिलकर गलत रिकॉर्ड क्यों बनाते हैं?

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

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

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

असंगतता कहां झूठी सफलता बन जाती है

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

हर पंक्ति में ढांचा एक ही है: असंगतता वह इनपुट हटा देती है जो नाकामी को चालू करता। ऐसे रिकॉर्ड से भरा टेस्ट सूट कमज़ोर इसलिए नहीं कि उसमें एसर्शन नहीं हैं; वह इसलिए कमज़ोर है कि उसके इनपुट उन शाखाओं तक पहुंचते ही नहीं जहां एसर्शन बैठे हैं।

असंगत डेटा अस्वीकार करना चाहिए या ठीक करना?

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

जनरेटर के लिए मोटा नियम यह है कि असंगतता जनरेटर में एक खामी है, ऐसा गुण नहीं जिसे आगे की परतें सह लें। इसके उलट करने पर टीम ऐसा कोड लिखना सीख जाती है जो सब कुछ सह लेता है, और बाद में असली इनपुट मिलने पर उसे भी निगल जाता है।

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

सुसंगतता का नियम कितना सख्त होना चाहिए?

उसे उतना ढीला रखिए जितना वह रह सके और फिर भी वे नाकामियां पकड़ ले जो मायने रखती हैं, और साफ़ बताइए कि वह कौन सी श्रेणी का है। नियम तीन ताक़तों में आते हैं, और उन्हें बिना लेबल मिला देने से ही कोडबेस में ऐसा सत्यापन बैठ जाता है जिसे कोई समझा नहीं सकता।

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

इस क्षेत्र की ज़्यादातर उलझन इसी से आती है कि सांख्यिकीय संबंध को कठोर नियम मान लिया जाता है। टेलीफ़ोन प्रीफ़िक्स आम तौर पर देश बताता है, पर हमेशा नहीं; पोस्टल कोड आम तौर पर क्षेत्र बताता है, पर सीमावर्ती इलाक़े और अपवाद मौजूद हैं। किसी प्रवृत्ति को पाबंदी बना देने से असली लोग अस्वीकार होते हैं, और यह सबसे ज़्यादा उन उपयोगकर्ताओं के साथ होता है जो डेटा की धारणाओं से सबसे कम मिलते हैं।

क्या बनाए गए रिकॉर्ड पूरे बैच में सुसंगत होने चाहिए?

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

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

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

व्यवहार में कौन सी जोड़ियां सबसे ज़्यादा टूटती हैं?

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

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

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

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

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

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

अगले कदम

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