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