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

टेस्ट केस क्वालिटी और रिव्यू

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

Test case review, testware पर लागू की गई static testing है: author के अलावा कोई दूसरा व्यक्ति test cases को test basis और एक तय checklist के सामने जाँचता है, उनके run होने या regression suite में जुड़ने से पहले। ISTQB Foundation syllabus उन work products में test cases को भी गिनाता है जिन्हें static testing जाँच सकती है, इसलिए requirements module वाले review types यहाँ भी लागू होते हैं।

मान लीजिए एक case का title "Order cancel करें" है और expected result "Order सही तरह cancel होता है"। हर field भरा है। लेकिन user story खोलकर बैठा reviewer देखता है कि इसमें कोई order तय नहीं, यह किसी acceptance criterion से trace नहीं होता, और यह fail हो ही नहीं सकता, क्योंकि "सही तरह" observe नहीं किया जा सकता।

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

एक test case कई बार run होता है, और उसका result ही team report करती है। Vague expected result वाला case हर हाल में pass होता है, तो असली defect production तक पहुँच सकता है जबकि report कहती है कि requirement test हो चुकी है। Missing precondition उल्टा करता है: case सही product पर fail होता है और developer ऐसे bug के पीछे भागता है जो है ही नहीं।

Execution से पहले fix बस कुछ lines बदलना है। Test cases आपके काम का दिखने वाला record भी हैं: नए team members इन्हीं से product सीखते हैं और automation engineers इन्हें scripts में बदलते हैं।

अच्छा test case किन बातों से बनता है

ISTQB glossary test case को preconditions, inputs, actions, expected results और postconditions बताता है, जो test conditions से बनते हैं। इनमें से कोई भी हिस्सा गलत, अधूरा या अस्पष्ट हो सकता है। Quality attributes की कोई एक standard list नहीं है, पर ज़्यादातर review checklists इन्हीं पर आकर टिकती हैं:

  • Traceable: case उस requirement, acceptance criterion या risk का नाम लेता है जिसे वह cover करता है।
  • Correct: expected result test basis से आता है, इस बात से नहीं कि system आज क्या करता है।
  • Unambiguous: कोई भी दो testers एक ही actions करेंगे और result को एक जैसा judge करेंगे।
  • Verifiable: हर expected result किसी observable चीज़ का नाम लेता है, जैसे value, message या status।
  • Focused: case एक behaviour जाँचता है, ताकि failure एक cause की ओर इशारा करे।
  • Independent और repeatable: case अपनी ज़रूरत की चीज़ें लिखता या बनाता है और किसी भी order में वही result देता है।
  • Maintainable और तय level of detail वाला: जहाँ team को exact values चाहिए वहाँ exact, और shared steps copy करने की जगह refer किए गए।

Test case review की checklist

Cases का review पहले run से पहले, regression suite में जुड़ने से पहले, और तब करें जब वह requirement बदले जिससे वे trace होते हैं। ज़्यादातर cases के लिए informal peer review काफ़ी है: कोई दूसरा tester story खोलकर उन्हें पढ़ता है।

Checklist छोटी रखें और उसे उन defects से बढ़ाएँ जो आपको सच में मिलते हैं। शुरुआत के लिए:

  • Basis: क्या case बताता है कि वह क्या cover करता है, और क्या वह item अब भी वही कहता है जो case मानता है?
  • Title: क्या यह एक behaviour और उसकी condition बताता है?
  • Preconditions: क्या हर ज़रूरी state लिखी है, जैसे role, record status और settings?
  • Test data: क्या exact, synthetic values दी गई हैं, या कोई named data set?
  • Steps: क्या हर step एक साफ़ action है जिसे नया team member ठीक लिखे अनुसार follow कर सके?
  • Expected results: क्या हर result observable, specific और test basis से लिया गया है?
  • Focus और independence: क्या case एक behaviour जाँचता है और अकेले, किसी भी order में सही चलता है?
  • Set: क्या हर acceptance criterion covered है, क्या negative और boundary cases हैं, और क्या duplicates हैं?

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

Review में test cases के कौन-से defects मिलते हैं

किसी भी दूसरे work product की तरह test cases में भी defects होते हैं। नीचे का हर type case को तब pass कराता है जब उसे fail होना चाहिए, तब fail कराता है जब pass होना चाहिए, या coverage बढ़ाए बिना समय खाता है।

  • Vague expected result ("works correctly", "error दिखता है"): case हर हाल में pass होता है।
  • System से copy किया गया expected result: अगर वह behaviour गलत था, तो case अब defect को ही सही ठहराता है।
  • Missing precondition या data: case product से असंबंधित कारणों से fail होता है, या सिर्फ़ author के data के साथ pass होता है।
  • एक case में कई behaviours: failure से पता नहीं चलता कि कौन-सा behaviour टूटा।
  • Hidden dependency: case तभी चलता है जब कोई दूसरा case उसका data बना दे।
  • Outdated case: requirement बदल गई, case नहीं बदला।
  • Duplicates: दो cases अलग titles से एक ही condition test करते हैं।
  • Set में gaps: कोई acceptance criterion, negative path या role जिसका कोई case ही नहीं।

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

Worked example: order cancellation वाले case का review

Story ORD-31 customer को order ship होने से पहले cancel करने देती है। AC1: Placed या Paid status वाला order My orders से confirmation के बाद cancel हो सकता है। AC2: cancel हुए order का status Cancelled दिखता है और original payment method पर पूरा refund शुरू होता है। AC3: Shipped order में Cancel order button नहीं दिखता।

एक colleague ने TC-ORD-07 लिखा है। आप story खोलकर इसका review करते हैं और हर finding को major (case गलत result दे सकता है) या minor (पढ़ने या maintain करने में मुश्किल) mark करते हैं।

पहली बार लिखा गया TC-ORD-07, line by line: ID और steps 1 और 2 review में pass होते हैं, title एक minor finding है, और खाली requirement, तय न किया गया order, मिला-जुला step 3, vague expected result और uncovered AC3 major findings हैं।

Story ORD-31 का TC-ORD-07, review से पहले

भाग 1:ID:              TC-ORD-07
भाग 2:Title:           Order cancellation
भाग 3:Requirement:     -
भाग 4:Preconditions:   User is logged in
भाग 5:Test data:       Any order
भाग 6:Steps:
  1. Open My orders and select the order
  2. Click "Cancel order" and confirm
भाग 7:  3. Check the refund and that a shipped order cannot be cancelled
भाग 8:Expected result:
  Order is cancelled correctly and the refund works
  1. 1IDStable और unique, ताकि bug reports और test reports इसका हवाला दे सकें।पास
  2. 2TitleFeature का नाम है, test होने वाले behaviour का नहीं।Title: Paid order can be cancelled before it shipsminorसावधानी
  3. 3RequirementTrace नहीं: कोई नहीं बता सकता कि case कौन-से acceptance criteria cover करता है।Requirement: ORD-31 AC1, AC2majorफ़ेल
  4. 4PreconditionsOrder के बारे में कुछ नहीं कहता: shipped order के साथ case सही product पर fail होता है।Her order ORD-1042 has status Paidmajorफ़ेल
  5. 5Test dataहर run में अलग order, और refund मिलाने के लिए कोई amount नहीं।ORD-1042: 349.00 SAR, paid by cardmajorफ़ेल
  6. 6Steps 1 और 2साफ़ actions जिन्हें नया team member follow कर सकता है; rework में बस dialog के button का नाम जुड़ता है।पास
  7. 7Step 3AC2 और AC3 को एक साथ जाँचता है, और AC3 के लिए shipped order चाहिए, इसलिए उसे अपना अलग case मिलता है।TC-ORD-08 (ORD-31 AC3)majorफ़ेल
  8. 8Expected result“सही तरह” और “काम करता है” observe नहीं हो सकते, इसलिए case fail ही नहीं हो सकता।Status "Cancelled"; refund of 349.00 SAR "Started"majorफ़ेल
  9. 9Case में नहीं: ORD-31 का बाकी हिस्साकोई case AC3 cover नहीं करता, न ही ऐसे Placed order का cancel होना जिसका payment अभी नहीं हुआ; review दो cases जोड़ता है।TC-ORD-08 (AC3), TC-ORD-09 (AC1)major · setफ़ेल

फ़ेल का मतलब major finding और सावधानी का मतलब minor finding है; किसी हिस्से के नीचे वाली line review के बाद उसका fix है।

  • Pass: ID, और steps 1 और 2, साफ़ actions जिन्हें नया team member follow कर सकता है। Rework में बस dialog के button का नाम जोड़ा गया है।
  • Title, minor: feature का नाम है, behaviour का नहीं। सुझाव: "Paid order ship होने से पहले cancel हो सकता है"।
  • Requirement, major: खाली है, जबकि case ORD-31 के AC1 और AC2 cover करता है।
  • Preconditions और test data, major: "कोई भी order" shipped order हो सकता है, जो सही product पर fail होगा, और मिलाने के लिए कोई refund amount नहीं देता।
  • Step 3, major: यह AC2 और AC3 को साथ जाँचता है, जबकि AC3 को shipped order और अपना अलग case चाहिए।
  • Expected result, major: "सही तरह" और "काम करता है" observe नहीं हो सकते, इसलिए case fail ही नहीं हो सकता।
  • Set, major: कोई case AC3 cover नहीं करता, न ही ऐसे Placed order का cancel होना जिसका payment अभी नहीं हुआ।
पाठ संस्करण
ID:              TC-ORD-07
Title:           Order cancel करना
Requirement:     -
Preconditions:   User logged in है
Test data:       कोई भी order
Steps:
  1. My orders खोलें और order चुनें
  2. "Cancel order" पर click करें और confirm करें
  3. Refund जाँचें, और यह भी कि shipped order cancel नहीं हो सकता
Expected result:
  Order सही तरह cancel होता है और refund काम करता है

Findings record करना और rework जाँचना

हर finding वहाँ log करें जहाँ author उसे देखेगा: case ID, checklist item, क्या गलत है और सुझाया गया fix। Case पर comment करें, व्यक्ति पर नहीं। कुछ findings requirement की ही कमी होती हैं: AC2 हर cancelled order पर refund का वादा करता है, लेकिन Placed order का payment हुआ ही नहीं। Test case में अंदाज़ा लगाने की जगह product owner से पूछें।

फिर पुराने और नए versions को line by line मिलाकर rework जाँचें। आम exit rule है: कोई open major finding नहीं। Rework के बाद का case और review में जोड़े गए cases:

ID:              TC-ORD-07
Title:           Paid order ship होने से पहले cancel हो सकता है
Requirement:     ORD-31 AC1, AC2
Preconditions:   Customer sara.k@example.com signed in है
                 उनके order ORD-1042 का status Paid है
Test data:       ORD-1042: 349.00 SAR, card से paid
Steps:
  1. My orders खोलें और ORD-1042 चुनें
  2. "Cancel order" पर click करें
  3. Dialog में "Yes, cancel" पर click करें
Expected result:
  - My orders में ORD-1042 का status "Cancelled" दिखता है
  - "Cancel order" button अब नहीं दिखता
  - Order details में card पर 349.00 SAR का refund, status "Started", दिखता है

Review में जोड़े गए:
  TC-ORD-08  Shipped order में "Cancel order" button नहीं दिखता      (ORD-31 AC3)
  TC-ORD-09  Placed order, जिसका payment अभी नहीं हुआ, cancel हो सकता है  (ORD-31 AC1)

आज़माएँ: टेक्स्ट डिफ़ आज़माएँ: AI टेस्ट केस ऑप्टिमाइज़र

आम गलतियाँ

  • Test basis खोले बिना review करना: इससे format जँचता है, correctness नहीं।
  • सिर्फ़ यह देखना कि हर field भरा है।
  • Findings log करने की जगह author के cases चुपचाप दोबारा लिख देना, जिससे किसी को पता नहीं चलता कि क्या बदला और क्यों।
  • Line, checklist item और fix बताने की जगह vague या personal comments ("unclear", "आप हमेशा preconditions भूल जाते हैं") लिखना।
  • Cases को एक-एक करके review करना और set को कभी नहीं।
  • Rework जाँचे बिना findings बंद कर देना।

QA का नज़रिया

Agile team में story के cases sprint के दौरान, लिखे जाने के कुछ ही देर बाद review होते हैं: कोई दूसरा tester उन्हें acceptance criteria के सामने पढ़ता है, और story का developer अक्सर गलत assumptions पकड़ लेता है। Regression suite के लिए चुने गए cases को दूसरी नज़र चाहिए, और requirement बदलने पर traceability बताती है कि कौन-से cases दोबारा review करने हैं।

हल्का record रखें: findings, उनका status और खुले सवालों पर फ़ैसले। Generated cases का review भी उसी checklist से करें, क्योंकि generator structure जानता है, आपके business rules नहीं।

अभ्यास

Email बदलने वाले test case का review करें

आपका काम

इस lesson की checklist से नीचे दिए TC-PRF-03 का story PRF-14 के सामने review करें। हर finding को उसके checklist item, major या minor, और सुझाए गए fix के साथ log करें।

फिर case दोबारा लिखें और बताएँ कि set को अब भी कौन-से cases चाहिए।

सामग्री
PRF-14  अपनी profile में email address बदलना
AC1  नया email तभी active होता है जब customer उस पर भेजा गया confirmation
     link खोलता है; तब तक पुराना email active रहता है।
AC2  Confirmation link भेजे जाने के 24 घंटे बाद expire हो जाता है।
AC3  जो email कोई दूसरा account पहले से इस्तेमाल करता है, वह इस message के
     साथ reject होता है: "This email is already in use"।

ID:              TC-PRF-03
Title:           Email बदलना
Requirement:     PRF-14
Preconditions:   -
Test data:       नया email
Steps:
  1. Log in करें और Profile पर जाएँ
  2. नया email डालें और Save पर click करें
  3. Confirmation email खोलें और link पर click करें
  4. पहले से मौजूद email के साथ फिर कोशिश करें
Expected result:
  Email बदल जाता है और error message दिखता है
चरण
  1. नोट करें कि case किन acceptance criteria को cover करने का दावा करता है।
  2. Checklist का हर item लागू करें और हर finding log करें।
  3. TC-PRF-03 को exact preconditions, data और observable expected results के साथ दोबारा लिखें।
  4. Uncovered acceptance criteria और product owner के लिए सवाल लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Title, minor: feature का नाम है; बेहतर: "नया email confirmation link खुलने के बाद ही active होता है"। Basis, minor: "PRF-14" story का नाम है, AC1 का नहीं। Preconditions, major: खाली हैं, इसलिए account और उसका मौजूदा email पता नहीं। Test data, major: "नया email" हर run में बदलता है और किसी दूसरे account का भी हो सकता है। Focus, major: step 4 AC1 वाले case के अंदर AC3 test करता है। Expected results, major: "Email बदल जाता है" AC1 की मूल बात छोड़ देता है, कि link खुलने तक पुराना email active रहता है, और "error message दिखता है" वह message नहीं बताता जो AC3 माँगता है।

Rework के बाद: customer omar.t@example.com signed in है; नया email omar.new@example.com किसी account में इस्तेमाल नहीं होता। 1. Profile में नया email डालें और Save पर click करें। 2. Sign out करके पुराने email से sign in करें। 3. नए email पर भेजा गया link खोलें। Expected: step 1 के बाद Profile में पुराना email ही दिखता है और omar.new@example.com पर confirmation email आता है; step 2 सफल होता है; step 3 के बाद नया email दिखता है।

Set को AC3 के लिए TC-PRF-04 और AC2 के लिए TC-PRF-05 चाहिए; developers से पूछें कि test environment में expired link कैसे बनाया जाए। Product owner से: क्या customer नया email confirm करने से पहले उससे sign in कर सकता है?

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

Test cases का review किसे करना चाहिए?

आदर्श रूप से कोई दूसरा tester जो feature जानता हो, test basis सामने रखकर। Business rules वाले expected results के बारे में product owner या business analyst से, और technical details के बारे में developer से पूछें। पहले अपने cases खुद checklist से review करें, लेकिन self-review दूसरे पढ़ने वाले की जगह नहीं ले सकता: author वही पढ़ता है जो उसका मतलब था, वह नहीं जो उसने लिखा।

क्या हर test case को formal review चाहिए?

नहीं। Formality को risk के हिसाब से चुनें। ज़्यादातर cases के लिए informal peer review ठीक है, team के सामने नया suite लाते समय walkthrough काम आता है, और payments, security या regulated features के लिए moderator के नेतृत्व में checklist और findings log वाला technical review या inspection ठीक रहता है।

क्या generated या AI से लिखे test cases को review चाहिए?

हाँ, उसी checklist से। Generators और AI tools जल्दी अच्छे structure वाले cases बना देते हैं, लेकिन वे आपके business rules नहीं जानते, ऐसा behaviour लिख सकते हैं जो requirement में नहीं है, और अक्सर आपके product की ख़ास बातें छोड़ देते हैं। उनके output को first draft मानें।

अगर author किसी finding से सहमत न हो तो?

Test basis पर वापस जाएँ। अगर वह सवाल सुलझा देता है, तो case उसी के हिसाब से चलेगा। अगर नहीं, तो सवाल product owner के पास जाता है, और फ़ैसला record किया जाता है ताकि अगला reviewer उसे फिर न खोले।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • ISO/IEC 20246:2017 — Software and systems engineering — Work product reviewsISO/IEC · 2017वर्क प्रोडक्ट की समीक्षा का सामान्य फ़्रेमवर्क — review प्रक्रिया, भूमिकाएँ और review तकनीकें।
  • ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021टेस्ट दस्तावेज़ों के टेम्पलेट और सामग्री — test policy, strategy, plan, status व completion रिपोर्ट, incident रिपोर्ट।
टूल्स

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

Requirements → टेस्ट केस

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

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

User Story → टेस्ट केस

किसी user story (As a / I want / So that) को टेम्पलेट और heuristics की मदद से संरचित टेस्ट केस में बदलें।

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

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

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

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

टेक्स्ट डिफ़

दो टेक्स्ट की लाइन-दर-लाइन या शब्द-दर-शब्द तुलना करें और अंतर हाइलाइट करें।

फ़ॉर्मेटिंग

AI टेस्ट केस ऑप्टिमाइज़र

Mutqan AI से मौजूदा टेस्ट केस बेहतर बनाएँ: साफ़ स्टेप, सटीक अपेक्षित परिणाम, छूटी हुई पूर्व-शर्तें और बेहतर संरचना।

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

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

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

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

और गहराई से

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

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