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