मॉड्यूल 6 · टेस्ट सिनेरियो और टेस्ट केस

रीयूज़ेबल और रिग्रेशन टेस्ट केस

Mutqan Soft QA टीम द्वारा · · 17 मिनट · शुरुआती

Reusable test case एक बार लिखा जाता है और कई बार चलाया जाता है, अलग-अलग data के साथ और अलग-अलग suites में। आप steps एक बार लिखते हैं, बदलने वाली values को data table में रखते हैं, और common set-up, जैसे login, को एक shared block में रखते हैं। Regression test case वह case है जिसने regression suite में जगह पाई है: वे cases जो changes के बाद दोबारा चलाए जाते हैं ताकि जाँचा जा सके कि जो पहले काम करता था वह अब भी काम करता है।

उदाहरण: एक shop ग्राहक को किसी item की 1 से 10 units cart में जोड़ने देती है। One-off तरीका 1, 10, 0 और 11 units के लिए चार cases लिखता है, और हर case login के steps दोहराता है। Reusable तरीका एक case लिखता है, "<qty> units cart में जोड़ें", quantities और expected results की table के साथ।

यह क्यों ज़रूरी है

Test cases जितनी बार लिखे जाते हैं, उससे कहीं ज़्यादा बार चलाए जाते हैं। Copy किए गए steps अलग होते जाते हैं: एक copy update होती है, तीन नहीं, और suite ऐसे कारणों से fail होता है जो defects नहीं हैं। Reusable cases हर step और हर value को एक ही जगह रखते हैं, इसलिए नई login screen या नई limit सिर्फ़ एक जगह बदलनी पड़ती है।

Regression suite तभी तक काम का है जब तक team उस पर भरोसा करती है और उसे चला पाती है। जो suite सिर्फ़ बढ़ता जाता है, वह duplicates और हटाए गए features के cases से भर जाता है, बहुत धीमा हो जाता है, और समय कम होने पर छोड़ दिया जाता है — ठीक तब जब उसकी ज़रूरत होती है।

One-off से reusable test case तक

One-off test case तीन चीज़ें मिला देता है: किसी behaviour को जाँचने वाले steps, data values, और वह set-up जिसकी steps को ज़रूरत है। एक बार चलने वाली जाँच के लिए यह ठीक है, लेकिन जैसे ही case को दूसरी value के लिए copy किया जाता है, यह महँगा हो जाता है।

Reusable test case इन तीनों को अलग रखता है। ISTQB glossary के terms में, placeholders के साथ लिखा गया case एक high-level (logical) test case है: उसके inputs और expected results abstract होते हैं। उसकी table में ठोस values की हर row उसे एक low-level (concrete) test case बना देती है, जिसका अपना expected result और अपना pass या fail होता है।

  • Parameterised: steps में fixed values की जगह <qty> जैसे placeholders होते हैं।
  • Data-driven: values और expected results की एक table runs को चलाती है, हर run के लिए एक row।
  • Shared steps: कई cases को जिस set-up की ज़रूरत होती है, जैसे login, वह एक बार लिखा जाता है और उसकी ID से refer किया जाता है।
Cart quantity rule, 1 से 10 units: चार one-off cases login दोहराते हैं और values steps में ही fix रखते हैं; एक reusable case steps एक बार, values data table में और login shared block SS-01 में रखता है।

एक बार वाले test cases

चार cases, हर quantity के लिए एक: 1, 10, 0 और 11

Steps:
हर case में फिर से लिखे जाते हैं
Values:
Steps के अंदर fixed
Login और product set-up:
हर case में copy
2.5 जैसी value जोड़ना:
पूरा case copy करके edit करें
Limit 10 से 20 हो जाती है:
Limit इस्तेमाल करने या उसका ज़िक्र करने वाला हर case ढूँढकर edit करें
Login page बदलता है:
हर case edit करें
दर्ज होने वाले results:
हर case का एक

रीयूज़ेबल test case

<qty>, data table और shared block SS-01 के साथ TC-CART-010

Steps:
एक बार लिखे जाते हैं
Values:
Data table में हर value की एक row, type tag के साथ
Login और product set-up:
Shared block SS-01, उसकी ID से refer
2.5 जैसी value जोड़ना:
एक row जोड़ें
Limit 10 से 20 हो जाती है:
सिर्फ़ table edit करें: 10 और 11 की जगह 20 और 21
Login page बदलता है:
सिर्फ़ SS-01 edit करें
दर्ज होने वाले results:
हर row का एक

Worked example: एक case, कई data rows

Requirement: "ग्राहक किसी item की 1 से 10 units cart में जोड़ सकता है। अगर stock माँगी गई quantity से कम है, तो कुछ नहीं जुड़ता और एक message बताता है कि कितनी units बची हैं।" नीचे हर row पर उसके type का tag और उसका अपना expected result है, और messages screen design से लिए गए हैं; stock एक अलग column है क्योंकि एक row को अलग value चाहिए।

Case को row-दर-row चलाएँ और हर row का एक result दर्ज करें। अगर limit 10 से 20 हो जाए, तो आप सिर्फ़ table बदलते हैं: 10 और 11 की जगह 20 और 21 आते हैं, और messages में नई limit आ जाती है; steps वही रहते हैं। वही table CSV file (comma-separated values: plain text में table, हर line में एक row) के रूप में save करें तो वह automated test को data दे सकती है: ISTQB glossary data-driven testing को एक scripting technique बताती है जो test data और expected results को data files में रखती है, जिन्हें test scripts इस्तेमाल करती हैं।

TC-CART-010   किसी product की <qty> units cart में जोड़ें
Precondition: SS-01 customer के रूप में login करें और product P-200 खोलें
              (stock level row के अनुसार)
Steps:        1. Quantity field में <qty> डालें
              2. "Add to cart" चुनें
Expected:     <expected>

Row  Type      qty      stock  expected
R1   positive  3        50     added: cart में 3 x P-200
R2   boundary  1        50     added: cart में 1 x P-200
R3   boundary  10       50     added: cart में 10 x P-200
R4   boundary  0        50     refused: "1 से 10 तक की quantity डालें"
R5   boundary  11       50     refused: "आप ज़्यादा से ज़्यादा 10 units जोड़ सकते हैं"
R6   negative  2.5      50     refused: "पूरी संख्या डालें", cart नहीं बदलता
R7   edge      (empty)  50     refused: "1 से 10 तक की quantity डालें"
R8   edge      5        4      refused: "Stock में सिर्फ़ 4 बचे हैं", cart नहीं बदलता

आज़माएँ: टेस्ट केस जनरेटर आज़माएँ: CSV डेटासेट जनरेटर

Shared steps: common set-up एक बार लिखें

कई cases जिस set-up को साझा करते हैं, जैसे login और product खोलना, उसे एक बार shared step block के रूप में उसकी अपनी ID के साथ लिखें, जैसे SS-01। जब login page में one-time password का step जुड़ जाए, तो आप SS-01 update करते हैं और उसे इस्तेमाल करने वाला हर case फिर से current हो जाता है। Test management tools अक्सर इसे shared steps कहते हैं; spreadsheet में block की ID का reference वही काम करता है।

  • Block को set-up और navigation तक सीमित रखें। Case जो behaviour जाँचता है वह उसी case में रहे, जहाँ उसे चलाने वाला उसे देख सके।
  • Block को एक checkpoint पर ख़त्म करें, जैसे "P-200 का page दिख रहा है", ताकि set-up की समस्या case के fail के रूप में report न हो।
  • Block बदलने से पहले देखें कि कौन-से cases उसे इस्तेमाल करते हैं: एक feature के लिए किया गया change बाकी cases को तोड़ सकता है।

एक suite में positive, negative, boundary और edge cases

हर row पर उसके type का tag कमियाँ दिखा देता है: अगर सारी rows positive हैं, तो suite सिर्फ़ happy path साबित करता है, चाहे उसमें कितनी भी rows हों। Balance का मतलब बराबर संख्या नहीं, बल्कि यह है कि हर rule का accept और reject होने वाला पक्ष cover हो। Quantity rule के लिए:

  • Positive: valid input और इरादे के मुताबिक़ इस्तेमाल, जैसे 3 units। Item जुड़ जाता है।
  • Negative: invalid input, जैसे 2.5। यह साफ़ message के साथ reject होता है और cart नहीं बदलता।
  • Boundary: सबसे छोटी और सबसे बड़ी allowed values और उनके ठीक बाहर वाले पड़ोसी: 1, 10, 0 और 11।
  • Edge: कोई एक input या हालत अपने extreme पर, जैसे खाली field, या लगभग ख़त्म हो चुका item: 5 माँगे गए और सिर्फ़ 4 बचे हैं।

आज़माएँ: बाउंड्री नंबर डेटासेट जनरेटर आज़माएँ: नेगेटिव टेस्ट जनरेटर

Regression suite बनाना और maintain करना

Confirmation और regression testing वाले lesson ने दिखाया कि किसी change के बाद कौन-से tests चलाने हैं; यह section ख़ुद suite के बारे में है। कोई case उसमें तब आता है जब वह ऐसे behaviour की रक्षा करता है जिसे काम करते रहना चाहिए और उसका expected result stable है। हर case पर उसकी priority के आधार पर tier का tag लगाएँ, जैसे हर build के लिए core और nightly run के लिए full, और suite को किसी तय समय पर review करें, जैसे हर release के अंत में।

  • Promote करें: critical journeys, high-priority rules, पहले टूट चुके areas, और हर उस fixed defect के लिए एक case जिसे suite पहले से cover नहीं करता था।
  • बाहर रखें: एक बार की जाँचें और duplicates। जो feature अब भी हर sprint में बदल रहा है, उसके cases तब तक रुकते हैं जब तक उसका behaviour stable न हो जाए।
  • Update करें: जब कोई requirement बदले, तो प्रभावित expected results उसी sprint में बदलें जिसमें code बदलता है।
  • Merge और retire करें: एक ही behaviour जाँचने वाले cases एक बन जाते हैं; हटाए गए features के cases कारण के साथ archive होते हैं।
  • Repair करें: जो case बिना product defect के fail होता है, अस्पष्ट steps या अविश्वसनीय data की वजह से, उसे जल्दी ठीक करें।

आज़माएँ: रिग्रेशन सिनेरियो जनरेटर आज़माएँ: AI डुप्लिकेट टेस्ट केस डिटेक्टर

आम गलतियाँ

  • एक value बदलने के लिए case copy करना, उसकी data table में row जोड़ने की बजाय।
  • "सही काम करता है" जैसे expected results लिखना, जिससे किसी row को pass या fail तय नहीं किया जा सकता।
  • Table को सिर्फ़ positive rows से भरना, या ऐसी कई rows से जो सब एक ही चीज़ टेस्ट करती हैं।
  • हर नया case regression suite में जोड़ते जाना और कभी किसी case को update, merge या retire न करना।
  • Fixed defect का test बंद bug report में ही छोड़ देना, उसे regression case बनाने की बजाय।

QA का नज़रिया

नया shared block लिखने से पहले देखें कि कोई पहले से मौजूद है या नहीं, और दूसरे testers के साथ ID prefixes (TC-, SS-), type tags और tier tags पर सहमति बनाएँ। जो tests automate करता है उसे भी शामिल करें: अच्छी data table थोड़े बदलाव से automated test की data file बन सकती है।

हर regression case के लिए लिखें कि वह suite में क्यों है (critical journey, पुराना defect, business rule), उसका owner कौन है और उसका आख़िरी review कब हुआ। Release के अंत में developers और product owner के साथ देखें कि क्या बदला, फिर cases update, merge और retire करें।

अभ्यास

Copy किए गए coupon cases को एक reusable case में बदलें

आपका काम

नीचे के cases copy करके लिखे गए थे। इन्हें एक shared step block और data table वाले एक parameterised case के रूप में दोबारा लिखें, छूटी हुई rows जोड़ें, और तय करें कि regression suite में हर original case का क्या होगा।

सामग्री
Rule: SAVE10 से 50.00 SAR या उससे ज़्यादा के orders पर 10% छूट मिलती है।
      Codes case-sensitive नहीं हैं। OLD5 जैसे expired codes reject होते हैं।

TC-41  Login करें, 200.00 के items जोड़ें, cart खोलें, SAVE10 लगाएँ  -> 20.00 छूट
TC-42  Login करें, 49.99 के items जोड़ें, cart खोलें, SAVE10 लगाएँ   -> reject
TC-43  Login करें, 200.00 के items जोड़ें, cart खोलें, OLD5 लगाएँ    -> reject
TC-44  Login करें, 200.00 के items जोड़ें, cart खोलें, save10 लगाएँ  -> 20.00 छूट
TC-45  Login करें, 200.00 के items जोड़ें, cart खोलें, SAVE10 लगाएँ  -> 20.00 छूट
TC-46  Login करें, order में gift wrap जोड़ें -> gift wrap जुड़ गया
       (release 4.2 में gift wrap को product से हटा दिया गया)
चरण
  1. हर case जो set-up दोहराता है उसके लिए shared block लिखें, जो एक checkpoint पर ख़त्म हो।
  2. एक parameterised case लिखें, और TC-41 से TC-45 तक को type tags और expected results वाली rows में बदलें।
  3. वे rows जोड़ें जिनकी एक balanced suite में अब भी कमी है।
  4. हर original case के लिए तय करें: row के रूप में रखें, merge करें या retire करें, और उसका tier चुनें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Shared block SS-07: customer के रूप में login करें, <cart> SAR के items जोड़ें, cart खोलें। Checkpoint: cart total <cart> दिखाता है।

TC-COUPON-01 "<cart> SAR के cart पर <code> लागू करें"। Rows: positive, 200.00 के साथ SAVE10, 20.00 की छूट; boundary, 49.99 के साथ SAVE10, reject (minimum order); negative, 200.00 के साथ OLD5, reject (expired); positive, 200.00 के साथ save10, 20.00 की छूट।

छूटी हुई rows: boundary, 50.00 के साथ SAVE10, 5.00 की छूट; negative, ABC123 जैसा unknown code, reject; edge, खाली code, reject; negative, उसी cart पर SAVE10 दूसरी बार लगाना, छूट 20.00 ही रहती है और दोगुनी नहीं होती। Rule यह नहीं बताता कि दूसरी कोशिश पर कौन-सा message दिखे, इसलिए product owner से पूछें।

Suite: TC-41 से TC-44 तक rows बनते हैं; TC-45 TC-41 को दोहराता है, इसलिए merge होता है; TC-46 को "gift wrap 4.2 में हटाया गया" कारण के साथ retire किया जाता है। TC-COUPON-01 core tier में जाता है: यह तय करता है कि ग्राहक कितना भुगतान करते हैं।

अक्सर पूछे जाने वाले सवाल

क्या parameterised test case और automated data-driven test एक ही हैं?

दोनों का विचार एक है: steps एक बार लिखे जाते हैं और values एक table में होती हैं। Parameterised manual case को कोई व्यक्ति row-दर-row चलाता है; automation में data-driven testing का मतलब है कि script rows को CSV जैसी data file से पढ़ती है। Manual runs के लिए अच्छी तरह बनाई गई table आम तौर पर वही data file बन सकती है।

क्या हर test case regression suite में जाना चाहिए?

नहीं। Regression suite में वे cases होते हैं जो ऐसे behaviour की रक्षा करते हैं जिसे काम करते रहना चाहिए: critical journeys, ज़रूरी rules और पुराने defects। एक बार की जाँचें और duplicates बाहर रहते हैं, और हर sprint में अब भी बदलने वाले feature के cases उसके stable होने तक रुकते हैं; वरना suite हर change के बाद चलाने के लिए बहुत धीमा हो जाता है।

Regression suite को कितनी बार review करना चाहिए?

किसी तय समय पर, जैसे हर release या sprint के अंत में, और जब भी कोई requirement बदले। Suite के बहुत धीमे या अविश्वसनीय होने तक इंतज़ार करने का मतलब है कि team पहले ही उस पर भरोसा करना छोड़ चुकी है।

संदर्भ

  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
टूल्स

Mutqan tools से अभ्यास करें

टेस्ट केस जनरेटर

फ़ीचर के विवरण और फ़ील्ड सूची से संरचित टेस्ट केस (id, शीर्षक, पूर्व-शर्तें, स्टेप, अपेक्षित परिणाम, प्राथमिकता) जनरेट करें।

टेस्ट डिज़ाइन

CSV डेटासेट जनरेटर

कस्टम कॉलम, डेटा टाइप, पंक्ति संख्या और डिलिमिटर के साथ CSV फ़ाइलें जनरेट करें।

टेस्ट डेटा

नेगेटिव टेस्ट जनरेटर

फ़ॉर्म फ़ील्ड और API के लिए negative टेस्ट केस बनाएँ: खाली, null, ग़लत टाइप, बहुत लंबा, injection, अमान्य फ़ॉर्मेट।

टेस्ट डिज़ाइन

रिग्रेशन सिनेरियो जनरेटर

बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।

टेस्ट डिज़ाइन

AI डुप्लिकेट टेस्ट केस डिटेक्टर

Mutqan AI से किसी सूट में डुप्लिकेट और आपस में ओवरलैप करते टेस्ट केस खोजें और मर्ज करने की सिफ़ारिशें पाएँ।

टेस्ट ऑप्टिमाइज़ेशन AI

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा