टेस्ट केस कैसे लिखें

Draft का रिव्यू (स्टेप 1)। आपके शब्द अलग हो सकते हैं; इनमें से सात या ज़्यादा findings पूरा जवाब है। (1) कोई ID नहीं, इसलिए बग रिपोर्ट और test reports इस केस को रेफ़र नहीं कर सकतीं। (2) टाइटल "Transfer test" फ़ीचर का नाम लेता है, व्यवहार का नहीं। (3) कोई प्रीकंडीशन नहीं: शुरुआती balances लिखे नहीं हैं, इसलिए कोई नहीं बता सकता कि बाद में कौन-से balances अपेक्षित हैं। (4) स्टेप 2 केस को TC-DEP-03 के पहले चलने पर निर्भर बनाता है, इसलिए सूट किसी भी क्रम में नहीं चल सकता; केस को जो balance चाहिए, वह उसकी प्रीकंडीशन में होना चाहिए। (5) Customer और उसके accounts production से copy किए गए हैं: असली कस्टमर डेटा की टेस्ट केस में कोई जगह नहीं, banking में तो बिल्कुल नहीं; एक सिंथेटिक test customer इस्तेमाल करें। (6) टेस्ट डेटा धुँधला है: "कुछ पैसे" और "बड़ा amount" values नहीं हैं, इसलिए दो टेस्टर दो अलग टेस्ट चलाएँगे। (7) स्टेप 3 में कई एक्शन और तीन व्यवहार हैं — valid transfer, 20,000.00 SAR की limit और balance check — इसलिए फ़ेल होने पर कोई नहीं जानता कौन-सा हिस्सा टूटा। (8) "Transfer सही काम करता है और error दिखता है" को pass या fail नहीं ठहराया जा सकता: कौन-से balances, कौन-सा message, और क्या reference number दिखता है? (9) कोई प्राथमिकता, कोई टाइप और PAY-31 व उसके criteria तक कोई ट्रेसेबिलिटी नहीं। इनमें से चार गाइड में बताई गई आम गलतियाँ हैं: एक केस में कई चीज़ें टेस्ट करना (7), धुँधला अपेक्षित परिणाम (8), किसी दूसरे केस पर निर्भर स्टेप (4) और असली कस्टमर डेटा (5)।

बँटवारा (स्टेप 2): draft तीन व्यवहार टेस्ट करता है, इसलिए वह तीन केस बनता है — valid transfer (TC-PAY31-01), limit से ऊपर का amount (TC-PAY31-05) और balance से ऊपर का amount (TC-PAY31-09)। हर नेगेटिव केस सिर्फ़ एक नियम तोड़ता है: limit वाले केस savings account से transfer करते हैं, जिसका balance 20,000.00 SAR से ऊपर है, और balance वाले केस limit के अंदर के amounts इस्तेमाल करते हैं, ताकि फ़ेल होने पर एक ही नियम की ओर इशारा हो। सभी केस एक ही सिंथेटिक डेटा सेट से शुरू होते हैं, जिसे हर रन से पहले restore किया जाता है: test customer CUST-T-031, savings account SAV-2002 में 25,000.00 SAR और current account CUR-1001 में 5,000.00 SAR, दोनों active, कोई pending transaction नहीं; TC-PAY31-11 और TC-PAY31-12 अपने बताए shared account और दूसरे test customer को जोड़ते हैं।

TC-PAY31-01 पूरा (स्टेप 3)। टाइटल: अपने accounts के बीच transfer amount भेजता है और reference number दिखाता है। प्राथमिकता: High। टाइप: Positive, smoke के लिए भी उम्मीदवार। Requirement: PAY-31 AC1। प्रीकंडीशन: CUST-T-031 signed in है; SAV-2002 का available balance 25,000.00 SAR और CUR-1001 का 5,000.00 SAR है। टेस्ट डेटा: source SAV-2002, destination CUR-1001, amount 250.00। स्टेप: 1. "Transfers" खोलें। 2. "Between my accounts" चुनें। 3. "From" में SAV-2002 चुनें। 4. "To" में CUR-1001 चुनें। 5. "Amount" में 250.00 डालें। 6. "Confirm" टैप करें। अपेक्षित परिणाम: reference number के साथ confirmation दिखता है; SAV-2002 में 24,750.00 SAR और CUR-1001 में 5,250.00 SAR दिखता है। पोस्टकंडीशन: दोनों balances बदल गए हैं; अगले रन से पहले डेटा सेट restore करें।

TC-PAY31-09 पूरा। टाइटल: Available balance से 0.01 SAR ज़्यादा का transfer "Insufficient balance" के साथ रिजेक्ट होता है। प्राथमिकता: High। टाइप: Negative, boundary। Requirement: PAY-31 AC3। प्रीकंडीशन: CUST-T-031 signed in है; CUR-1001 का available balance 5,000.00 SAR और SAV-2002 का 25,000.00 SAR है। टेस्ट डेटा: source CUR-1001, destination SAV-2002, amount 5000.01 — balance से 0.01 ज़्यादा, और AC2 की limit के अंदर, इसलिए सिर्फ़ AC3 टूटता है। स्टेप: 1. "Transfers" खोलें। 2. "Between my accounts" चुनें। 3. "From" में CUR-1001 चुनें। 4. "To" में SAV-2002 चुनें। 5. "Amount" में 5000.01 डालें। 6. "Confirm" टैप करें। अपेक्षित परिणाम: message "Insufficient balance" दिखता है; न confirmation दिखता है, न reference number; CUR-1001 में अब भी 5,000.00 SAR और SAV-2002 में 25,000.00 SAR दिखता है। पोस्टकंडीशन: कुछ नहीं, balances नहीं बदले।

बाकी सेट (स्टेप 4), हर केस की एक लाइन; ऊपर के दो केस मिलाकर कुल 14 केस। TC-PAY31-02 [Boundary · AC2] SAV-2002 से amount 1.00, निचला किनारा: स्वीकार; SAV-2002 में 24,999.00 और CUR-1001 में 5,001.00। TC-PAY31-03 [Boundary · AC2] Amount 0.99: "Confirm" disabled रहता है, field के नीचे message "Enter an amount from 1.00 to 20,000.00 SAR" दिखता है, और कोई balance नहीं बदलता। TC-PAY31-04 [Boundary · AC2] SAV-2002 से amount 20000.00, ऊपरी किनारा: स्वीकार; SAV-2002 में 5,000.00 और CUR-1001 में 25,000.00। TC-PAY31-05 [Boundary · AC2] SAV-2002 से amount 20000.01: "Confirm" disabled रहता है और वही message दिखता है; 25,000.00 का balance पक्का करता है कि सिर्फ़ limit टूटे। TC-PAY31-06 [Negative · AC2] तीन decimal places वाला amount 10.005: स्वीकार नहीं; message दिखता है या तीसरा decimal टाइप ही नहीं होता, यह Q1 है। TC-PAY31-07 [Negative · AC2] "Amount" खाली छोड़ा गया: "Confirm" disabled रहता है (message भी दिखता है या नहीं, यह Q1 का हिस्सा है)।

TC-PAY31-08 [Boundary · AC3] Available balance के बराबर amount, CUR-1001 से 5000.00: स्वीकार, क्योंकि AC3 शून्य से नीचे जाना मना करता है, शून्य तक पहुँचना नहीं; CUR-1001 में 0.00 और SAV-2002 में 30,000.00। TC-PAY31-10 [Negative · AC1] "From" में SAV-2002 चुनने के बाद उसे "To" में नहीं चुना जा सकता; यह कैसे दिखता है, यह Q3 है। TC-PAY31-11 [Negative · रोल] किसी दूसरे customer ने CUST-T-031 के साथ view-only access से जो account share किया है (VIEW-3003), वह "From" में नहीं दिखता; "To" में दिखता है या नहीं, यह Q4 है। TC-PAY31-12 [Negative · AC1 की प्रीकंडीशन] Test customer CUST-T-032 के पास एक active और एक closed account है: closed account नहीं दिखता और कोई transfer नहीं हो सकता; customer को क्या दिखता है, यह Q5 है। TC-PAY31-13 [Negative · डिपेंडेंसी] "Confirm" के बाद core banking system जवाब नहीं देता (test environment में simulate किया गया, जैसे stub से): confirmation नहीं दिखता, और आधा-अधूरा transfer नहीं होता — या तो दोनों balances एक बार बदलते हैं या कोई नहीं बदलता; message और retry का व्यवहार Q6 है। TC-PAY31-14 [Negative · AC1, एक साथ किए एक्शन] SAV-2002 से CUR-1001 में 250.00 के साथ "Confirm" जल्दी-जल्दी दो बार टैप करना: सिर्फ़ एक transfer और एक reference number; SAV-2002 में 24,750.00 दिखता है, 24,500.00 नहीं, और CUR-1001 में 5,250.00। अगर आप गाइड का छह values वाला boundary पैटर्न (हर किनारे पर तीन values) अपनाते हैं, तो SAV-2002 से 1.01 और 19999.99, और balance वाले किनारे पर CUR-1001 से 4999.99 भी जोड़ें; तीनों स्वीकार।

कवरेज (स्टेप 5): AC1 को TC-PAY31-01, 10, 12, 13 और 14 कवर करते हैं; AC2 को 02 से 07; AC3 को 08 और 09; view-only रोल को 11। हर criterion का कम से कम एक पॉज़िटिव और एक नेगेटिव केस है। तीन criteria वाली story के लिए गाइड लगभग आठ से पंद्रह केस बताती है; पर सेट को पूरा उसकी गिनती नहीं बनाती, बल्कि यह कि हर criterion, हर बाउंड्री, हर तरह का यूज़र और डिपेंडेंसी का फ़ेल होना कवर हो।

Product owner के लिए सवाल: Q1 क्या तीसरा decimal टाइप करते समय ही रोका जाता है, या टाइप होने के बाद AC2 का message दिखता है? क्या वह message तब भी दिखता है जब "Amount" अभी खाली है? क्या thousands separator (1,000.00) या Arabic-Indic digits वाले amounts स्वीकार होते हैं? Q2 क्या AC3 का "available balance" pending card payments और holds घटाकर गिना जाता है? Q3 क्या source account "To" की सूची से हट जाता है, या कोई message दिखता है? Q4 क्या view-only shared account में पैसे भेजे जा सकते हैं, या वह दोनों सूचियों से छिपा रहता है? Q5 जिस customer के दो से कम active accounts हैं, उसे "Between my accounts" में क्या दिखता है? Q6 जब core banking system जवाब न दे, तो कौन-सा message दिखता है, क्या customer retry कर सकता है, और क्या चीज़ retry को पैसे दो बार भेजने से रोकती है? Q7 क्या हर transfer की 20,000.00 SAR limit ही अकेली limit है, या कोई daily total भी है?

अपना काम जाँचें: हर पूरे केस का टाइटल एक व्यवहार का नाम ले, और आपकी सूची की हर लाइन एक ही व्यवहार जाँचे; हर केस किसी दूसरे केस से नहीं, बल्कि लिखी हुई प्रीकंडीशन से शुरू हो, सटीक सिंथेटिक values इस्तेमाल करे, और उसका अपेक्षित परिणाम ऐसा हो जिसे दो टेस्टर एक ही तरह जाँचें। ISTQB की भाषा में PAY-31 और उसके criteria test basis हैं, आपकी सूची की हर लाइन एक test condition कवर करती है, और हर पूरे केस में वे preconditions, inputs, expected results और postconditions हैं जो ISTQB glossary test case की परिभाषा में गिनाती है। अगर आपके सेट में TC-PAY31-08 (balance के बराबर amount), TC-PAY31-13 (डिपेंडेंसी का फ़ेल होना) या TC-PAY31-14 (डबल टैप) नहीं थे, तो उन्हें जोड़ें: पहला वह किनारा है जिसकी AC3 इजाज़त देता है, दूसरा डिपेंडेंसी का फ़ेल होना है, जिसे गाइड का user story वाला तरीका माँगता है, और तीसरा गाइड की नेगेटिव टेस्टिंग सूची के "एक साथ किए एक्शन" में से एक है।