मेन्यू

आयु सत्यापन टेस्टिंग: सीमाएं, सीमा रेखाएं और लीप डे

आयु सत्यापन टेस्टिंग के लिए तय संदर्भ तारीख़ें और हर सीमा के दोनों तरफ़ के मान चाहिए। यहां बताया गया है कि आम आयु द्वार कहां से आते हैं और उन्हें कैसे जांचें।

प्रकाशित

  • टेस्ट डेटा
  • पहचान
  • अनुपालन

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

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

अलग-अलग आयु सीमाएं कहां से आती हैं?

वे अलग-अलग नियमों से आती हैं जिनके मक़सद अलग हैं, और इसीलिए लागू करने के लिए कोई एक संख्या नहीं है।

सीमा वह आम तौर पर कहां आती है
13 संयुक्त राज्य अमेरिका के बच्चों की ऑनलाइन गोपनीयता नियम, जो कम उम्र के उपयोगकर्ताओं से डेटा इकट्ठा करने को नियंत्रित करते हैं
16 यूरोपीय डेटा संरक्षण नियमों के तहत सूचना समाज की सेवाओं के लिए सहमति की डिफ़ॉल्ट आयु, जिसे सदस्य देश एक दायरे में बदल सकते हैं
18 ज़्यादातर देशों में वयस्कता की आयु, और बहुत सारे अनुबंधों व सेवाओं का द्वार
21 कुछ क्षेत्राधिकारों में शराब और कुछ अन्य नियंत्रित गतिविधियों के लिए इस्तेमाल होने वाली ऊपरी सीमा

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

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

स्वयं घोषित जन्म तिथि क्या साबित कर सकती है?

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

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

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

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

सीमा मानों की जांच कैसे करें?

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

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

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

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

समय क्षेत्र जवाब कैसे बदल देते हैं?

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

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

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

लीप डे पर जन्मे लोगों का क्या?

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

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

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

डेवलपर्स के लिए: सीमाओं को कॉन्फ़िगर करने लायक बनाना

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

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

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

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

अगले कदम

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

आगे पढ़ें

पहचान और टेस्ट डेटा जनरेटर संबंधित गाइड

पहचान और टेस्ट डेटा जनरेटर संबंधित गाइड

यहाँ केवल इस पृष्ठ के विषय से जुड़े लेख दिखाए गए हैं।