मॉड्यूल 7 · Test design techniques

यूज़ केस टेस्टिंग

Mutqan Soft QA टीम द्वारा · · 17 मिनट · मध्यम

Use case testing एक black-box test design technique है जो use cases से tests बनाती है। Use case step by step बताता है कि कोई actor — यानी कोई user role या दूसरा system — एक लक्ष्य पाने के लिए system के साथ कैसे interact करता है: एक main flow (सामान्य रास्ता), alternative flows (दूसरे valid रास्ते) और exception flows (कुछ गलत होने पर क्या होता है) के ज़रिए। हर flow कम से कम एक test बनता है।

उदाहरण: "Online order देना" में एक test main flow पर saved card से payment करता है; दूसरा ऐसा card इस्तेमाल करता है जिसे payment gateway decline कर देता है, और जाँचता है कि कोई order नहीं बना और कोई पैसा नहीं कटा। जैसा test scenarios वाले lesson में देखा, हर flow एक तैयार scenario है; यह technique उन सबको खोजती है और coverage को गिनने लायक बनाती है।

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

Users tasks पूरे करते हैं, और tasks में शाखाएँ होती हैं। Defects अक्सर वहीं छिपे होते हैं जहाँ flow branch होता है, जहाँ वह main flow में लौटता है, और error handling में: timeout के बाद customer से दो बार पैसे कटना, बिना payment के order बन जाना, failed payment के बाद cart खाली हो जाना। Happy path के tests इन जगहों तक कभी पहुँचते ही नहीं, जबकि यहीं failures पैसे और भरोसे की कीमत वसूलती हैं।

Tester के लिए use case एक requirement को scenarios की गिनी जा सकने वाली list में बदल देता है। आप "checkout के छह में से पाँच flows pass हैं, timeout वाला flow fail है" report कर सकते हैं, न कि "checkout ज़्यादातर चलता है"। और use case को tester की नज़र से पढ़ने पर missing flows code लिखे जाने से पहले ही सामने आ जाते हैं।

Use case में क्या-क्या होता है

ISTQB की भाषा में use case किसी actor और system के बीच interactions का ऐसा क्रम है जिसका एक ठोस नतीजा निकलता है। Actor कोई user या ऐसी कोई भी चीज़ हो सकता है जो system के साथ जानकारी का लेन-देन करे; वह एक role है, कोई खास व्यक्ति नहीं: "customer" या "payment gateway"। Primary actor अपना लक्ष्य पाने के लिए use case शुरू करता है; supporting actors वे लोग या systems हैं जिनकी रास्ते में ज़रूरत पड़ती है।

Templates में नाम बदलते हैं — कुछ teams हर branch को "extension" कहती हैं — लेकिन हर branch को बताना होगा कि वह main flow को कहाँ छोड़ती है और कहाँ खत्म होती है। एक आम use case में ये हिस्से होते हैं:

  • Name: लक्ष्य, क्रिया के रूप में, जैसे "Online order देना"।
  • Precondition और trigger: शुरू होने से पहले क्या सच होना चाहिए, और कौन-सा event उसे शुरू करता है।
  • Main flow (जिसे basic flow या main success scenario भी कहते हैं): लक्ष्य तक के सामान्य रास्ते के numbered steps।
  • Alternative flows: बिना error वाले दूसरे valid रास्ते, जो आम तौर पर उसी लक्ष्य तक पहुँचते हैं, जैसे नए card से payment।
  • Exception flows: कुछ गलत होने पर system का जवाब — invalid input, कोई business rule जो step रोक दे, कोई supporting system जो मना कर दे या जवाब न दे। Flow या तो recover होता है, जिससे लक्ष्य अब भी पूरा हो सकता है, या use case लक्ष्य पाए बिना safely खत्म होता है।
  • Postconditions: अंत में क्या सच है, success पर (order save हुआ) और failure पर (कुछ charge नहीं हुआ, cart बचा रहा); failure वाला हिस्सा अक्सर भुला दिया जाता है।

Worked example: checkout का use case

एक business analyst ने online shop के लिए यह use case लिखा है। इसे tester की नज़र से पढ़ें: flows गिनें, और देखें कि हर flow main flow को कहाँ छोड़ता है और कहाँ खत्म होता है।

इसमें छह flows हैं: main flow, दो alternative flows और तीन exception flows। E1 recover होकर main flow में लौटता है; E2 और E3 बिना paid order के खत्म होते हैं, इसलिए उनके tests को वह जाँचना है जो नहीं होना चाहिए: दूसरी payment request, बिना order के charge, खोया हुआ cart।

UC-07  Online order देना
Primary actor:     Customer (signed in)
Supporting actor:  Payment gateway
Precondition:      Cart में कम से कम एक in-stock item है
Trigger:           Customer "Checkout" चुनता है

Main flow
1. System items, total और saved delivery address दिखाता है।
2. Customer address confirm करता है।
3. Customer saved card चुनकर "Pay" चुनता है।
4. System एक payment request भेजता है; gateway उसे approve करता है।
5. System order को Paid के रूप में बनाता है, stock घटाता है, cart खाली
   करता है और order number दिखाता है।

Alternative flows
A1 step 2 पर  Customer नया address जोड़ता है, system validate करता है। 3 पर लौटें।
A2 step 3 पर  Customer नया card डालता है। 4 पर लौटें।

Exception flows
E1 step 4 पर  Gateway decline करता है: system कारण दिखाता है। 3 पर वापस।
E2 step 4 पर  30 s में जवाब नहीं: system "Payment confirm हो रहा है" दिखाता है,
              order को Pending दर्ज करता है, दूसरी request नहीं भेजता। समाप्त।
E3 step 5 पर  Payment के दौरान कोई item sold out: system payment void करता है,
              cart रखता है और customer को बताता है। समाप्त।
Checkout use case UC-07: main flow के पाँच steps, उसमें लौटने वाले दो alternative flows और recover होने या safely खत्म होने वाले तीन exception flows — छह flows, यानी कम से कम छह tests।
  1. 1Items, total और saved address दिखानाTrigger: customer "Checkout" चुनता हैSystem
  2. 2Address confirm करनाCustomer

    शाखा: A1 · alternative: नया address, validate होकर → 3 पर लौटता है

  3. 3Saved card चुनकर "Pay" चुननाCustomer

    शाखा: A2 · alternative: नया card → 4 पर लौटता है

  4. 4एक payment request भेजना; gateway approve करता हैSystem + gateway

    दोहराता है: E1 · exception: decline → कारण दिखा → 3 पर वापस

    शाखा: E2 · exception: 30 s में जवाब नहीं → order Pending, दूसरी request नहीं; समाप्त

  5. 5Order Paid के रूप में बनाना, stock घटाना, cart खाली करनाOrder number दिखानाSystem

    शाखा: E3 · exception: item sold out → payment void, cart बचा; समाप्त

इसके बाद:लक्ष्य पूरा: order Paid, stock घटा, cart खाली

Dashed branches main flow को उसी step पर छोड़ती हैं जहाँ से वे शुरू होती हैं: alternative flows (A) फिर भी लक्ष्य तक पहुँचते हैं, exception flows (E) किसी गड़बड़ी को संभालते हैं।

Flows से test cases बनाना

हर flow एक coverage item है, इसलिए कम से कम हर flow का एक test चाहिए। Branch का test branch point तक main flow पर चलता है, branch को trigger करता है और उसके अंत तक जाता है। अगर branch आगे के किसी step पर main flow में लौटती है, जैसे A1 और A2, तो test main flow पूरा करता है ताकि दिखे कि लक्ष्य अब भी पूरा होता है। अगर वह किसी पिछले step पर वापस जाती है, जैसे E1, तो test जाँचता है कि actor उसी step पर लौटा और कोई काम अधूरा नहीं छूटा: न order, न charge।

  • Precondition → test setup; trigger → पहला step; postconditions → expected results।
  • सिर्फ़ screen नहीं, data जाँचें: order status, stock level, और gateway के test environment में payment record।
  • हर exception को trigger करने का तरीका पहले से तय करें: ऐसा test card जिसे gateway का sandbox (provider का चलाया service का test version) हमेशा decline करे, reply में देरी करने वाला stub (gateway की जगह लगाया गया हिस्सा, जिसे team control करती है), या दूसरा test user जो आख़िरी unit खरीद ले। जिस branch को कोई trigger नहीं कर सकता, वह चुपचाप testing से बाहर हो जाती है, इसलिए यह बात जल्दी उठाएँ।
  • Steps के अंदर पिछले lessons की techniques दोबारा लगाएँ: address fields के लिए boundary values, और order status (Pending, Paid) के लिए state transitions।
TC-07-01  Main: saved address और saved card
          Expected: order Paid, stock घटा, cart खाली, order number दिखा
TC-07-02  A1: step 2 पर नया valid address
          Expected: order Paid, उस पर नया address
TC-07-03  A2: step 3 पर नया test card
          Expected: नए card से order Paid
TC-07-04  E1: sandbox card जिसे gateway decline करता है
          Expected: कारण दिखा, step 3 पर वापस, कोई order नहीं, कोई charge नहीं
TC-07-05  E2: stub gateway reply को 30 s से ज़्यादा रोकता है
          Expected: message दिखा, order Pending, सिर्फ़ एक payment request गई
TC-07-06  E3: payment के दौरान दूसरा user आख़िरी unit खरीद लेता है
          Expected: payment void, कोई order नहीं, cart बचा, customer को सूचना

आज़माएँ: User Story → टेस्ट सिनेरियो आज़माएँ: Requirements → टेस्ट सिनेरियो

Use case coverage और उसकी सीमाएँ

Use case coverage = कम से कम एक test से exercise हुए flows ÷ पहचाने गए कुल flows, प्रतिशत में। जो suite सिर्फ़ main flow, A1 और E1 चलाता है, वह UC-07 के 6 में से 3 flows cover करता है: 50%। ऊपर के छह tests 100% तक पहुँचते हैं।

पूरी flow coverage न्यूनतम है। Risky use cases के लिए combinations जोड़ें, जैसे decline के बाद नया card (E1 फिर A2)। और flow coverage उन flows के बारे में कुछ नहीं कहती जिन्हें किसी ने लिखा ही नहीं, इसलिए हर step पर पूछें कि और क्या हो सकता है:

  • Actor cancel करता है, पीछे जाता है, या इतना रुकता है कि session expire हो जाए।
  • Actor कोई action दोहराता है: "Pay" पर double-click, या payment के दौरान refresh।
  • कोई supporting system धीमा है, उपलब्ध नहीं है, या दो बार जवाब देता है।
  • कोई दूसरा user उसी पल वही data बदल देता है।

आज़माएँ: Requirements → टेस्ट केस

आम गलतियाँ

  • सिर्फ़ main flow टेस्ट करके use case को पूरा मान लेना, जबकि branching और error handling बाकी flows में ही होते हैं।
  • Data में postconditions की जगह सिर्फ़ आख़िरी screen जाँचना, और exception flows में यह न जाँचना कि जो नहीं होना चाहिए था वह सच में नहीं हुआ।
  • Exception flows को "trigger करना मुश्किल है" कहकर छोड़ देना, बजाय इसके कि जल्दी test cards, stubs या data पर सहमति बने जो उन्हें reproducible बनाएँ।
  • एक लंबे test में कई branches से गुज़रना, जिससे failure यह नहीं बताता कि कौन-सा flow टूटा, और साफ़ नहीं रहता कि test ने असल में कौन-से flows cover किए। पहले हर flow को उसका अपना test दें।
  • Flow coverage पर रुक जाना: हर flow के लिए एक data value हर step के अंदर के inputs को नज़रअंदाज़ करती है, जिन्हें equivalence partitioning और boundary value analysis से cover करना अभी बाकी है।

QA का नज़रिया

Use cases आपको business analysts की लिखी functional specifications में मिलेंगे। Coding से पहले उन्हें review करें: क्या हर step testable है, क्या हर branch बताती है कि वह कहाँ खत्म होती है, क्या postconditions success के साथ failure के लिए भी लिखी हैं? सवाल "जब लक्ष्य पूरा न हो तब system क्या guarantee करता है?" अक्सर कोई अलिखित rule सामने लाता है, जैसे timeout हुए payment का निपटारा कैसे होगा।

हर test को उसके use case और flow से नाम या tag दें (UC-07/E2), ताकि आप हर use case की coverage report कर सकें और use case बदलने पर update होने वाले tests ढूँढ सकें। तब bug report में use case, flow और step होते हैं: "UC-07 E2, step 4: timeout के बाद दूसरी payment request भेजी जाती है"।

अभ्यास

Booking use case से tests बनाएँ और coverage मापें

आपका काम

एक clinic app में नीचे दिया use case है। Team के पास पहले से तीन tests हैं: TC-21-01 (main flow), TC-21-02 (A1) और TC-21-03 (E1)। पता करें कि क्या छूटा है, बाकी tests design करें, और पहले और बाद की use case coverage मापें।

सामग्री
UC-21  Clinic appointment book करना
Primary actor:     Patient (signed in)
Supporting actor:  SMS service
Trigger:           Patient "Book appointment" चुनता है

Main flow
1. Patient clinic और doctor चुनता है।
2. System अगले 14 दिनों के लिए doctor के free slots दिखाता है।
3. Patient एक slot चुनकर confirm करता है।
4. System slot book करता है, booking number दिखाता है और SMS service से
   confirmation भेजने को कहता है।
Postcondition: slot अब free नहीं है; booking "My appointments" में दिखती है।

Alternative flows
A1 step 1 पर  Patient doctor की जगह specialty से search करता है। 2 पर लौटें।
A2 step 3 पर  Patient confirm से पहले doctor के लिए note जोड़ता है। 4 पर लौटें।

Exception flows
E1 step 2 पर  14 दिनों में कोई free slot नहीं: system waiting list देता है। समाप्त।
E2 step 3 पर  दूसरे patient ने अभी-अभी वह slot book कर लिया: system यह बताता है
              और updated slots दिखाता है। 2 पर वापस।
E3 step 4 पर  SMS service उपलब्ध नहीं: booking बनी रहती है और दिखती है; system बाद
              में SMS भेजने की फिर कोशिश करता है। समाप्त।
चरण
  1. हर flow को उसकी id, branch point और अंत के साथ लिखें।
  2. मौजूदा तीन tests की coverage निकालें।
  3. हर untested flow के लिए लिखें कि उसे कैसे trigger करेंगे और screen व data में expected end state क्या है।
  4. दो ऐसी स्थितियाँ जिनका use case में ज़िक्र नहीं, business analyst के लिए सवालों के रूप में लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Flows: main; A1 (1 पर, 2 पर लौटता है); A2 (3 पर, 4 पर लौटता है); E1 (2 पर, बिना booking के खत्म); E2 (3 पर, 2 पर वापस); E3 (4 पर, booking हो जाने के साथ खत्म — exception flow का मतलब हमेशा actor के लिए failure नहीं होता)। कुल छह flows।

Coverage: पहले 6 में से 3 flows = 50%; A2, E2 और E3 के tests जोड़ने के बाद 6 में से 6 = 100%।

TC-21-04 (A2): note जोड़कर confirm करें; expected: screen पर booking number, booking के साथ note save, और slot अब free नहीं। TC-21-05 (E2): दो test patients दो browsers में एक ही slot चुनते हैं और एक के बाद एक confirm करते हैं; expected: दूसरे को message और updated slots, और सिर्फ़ एक booking। TC-21-06 (E3): SMS service को unavailable stub से बदलकर book करें; expected: booking number दिखे, booking "My appointments" में हो, और stub फिर उपलब्ध होने पर SMS जाए।

संभावित सवाल: क्या step 3 के दौरान slot अस्थायी रूप से hold होता है, और कितनी देर? क्या patient एक ही समय पर दो appointments book कर सकता है?

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

Use case और user story में क्या फ़र्क है?

User story किसी ज़रूरत का छोटा statement है, acceptance criteria के साथ, जिसका मक़सद बातचीत शुरू करना और एक iteration में समा जाना है। Use case पूरा interaction step by step बताता है, उसके alternative और exception flows समेत। Team एक use case को कई stories में बाँट सकती है; tests दोनों से बनाए जा सकते हैं, लेकिन use case branches की list आपको तैयार देता है।

क्या use case testing ISTQB Foundation syllabus का हिस्सा है?

अब अलग technique के रूप में नहीं। CTFL v4.0 चार black-box techniques बताता है: equivalence partitioning, boundary value analysis, decision table testing और state transition testing। Use case testing 2018 के syllabus में black-box techniques में से एक थी, और ISTQB glossary अब भी इसकी परिभाषा देती है। जहाँ requirements use cases के रूप में लिखी जाती हैं, वहाँ यह आज भी उपयोगी है।

एक use case को कितने tests चाहिए?

हर flow के लिए कम से कम एक, जिससे 100% use case coverage मिलती है। फिर risky combinations और loops के tests जोड़ें, और steps के अंदर data variations equivalence partitioning और boundary value analysis जैसी techniques से।

संदर्भ

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

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

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

किसी फ़ीचर के लिए functional, negative, security, usability और compatibility पहलुओं को कवर करने वाले उच्च-स्तरीय टेस्ट सिनेरियो जनरेट करें।

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

Requirements → टेस्ट केस

क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।

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

और गहराई से

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

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