बिलिंग फ़ॉर्म टेस्ट केस: वह मैट्रिक्स जो बग पकड़ता है

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

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

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

वह कम से कम पांच चीज़ें जमा करता है, और उनमें से चार बाद के हर सिस्टम में जाती हैं।

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

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

हर बिलिंग फ़ॉर्म को चार शाखाओं से क्यों गुज़ारना चाहिए?

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

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

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

एक ही फ़ील्ड अलग देशों में अलग क्यों बर्ताव करता है?

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

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

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

फ़ॉर्म के बाहर क्या गड़बड़ होता है?

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

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

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

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

डेवलपर्स के लिए: केस मैट्रिक्स और फिक्स्चर

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

इसके साथ चार फिक्स्चर रिकॉर्ड रखें, और इन्हें ऐसी काल्पनिक इकाइयों से बनाएं जो किसी असली कारोबार के न हों:

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

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

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

अगले कदम

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