मॉड्यूल 4 · टेस्ट प्रोसेस (STLC)

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

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

Test design वह test activity है जो test conditions को test cases और उन्हें चलाने के लिए ज़रूरी बाकी testware में बदलती है। Test analysis ने तय किया कि क्या टेस्ट करना है; test design तय करता है कि कैसे: कौन-से inputs, किस state में, कौन-से expected results, किस data पर और किस environment में।

उदाहरण: एक loyalty programme के analysis से condition निकली "points redeem करने के लिए member के पास कम से कम 500 points होने चाहिए"। Test design इसे गिनने लायक चार coverage items में, exact expected results वाले दो test cases में, और उन tests के लिए ज़रूरी data और environment की सूची में बदलता है।

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

Test design के बिना tests execution के दौरान उसी समय गढ़े जाते हैं: बीच की आरामदायक values के कई tests, किनारों पर एक भी नहीं, मौके पर अंदाज़े से लिखे expected results, और यह बताने का कोई तरीका नहीं कि condition का कितना हिस्सा टेस्ट हुआ। जो data और environments किसी ने पहले से नहीं माँगे, वे blocked days बन जाते हैं।

पहले किया गया design आपको अंदाज़े की जगह report करने लायक एक संख्या देता है ("4 में से 4 coverage items exercised"), और ऐसे test cases जिन्हें दूसरे लोग code बनने से पहले review कर सकें। Exact expected results लिखने से test basis की कमियाँ भी तब सामने आती हैं जब उन्हें ठीक करना अभी सस्ता होता है।

Test design में क्या आता है और उससे क्या निकलता है

Test design, test analysis के output से शुरू होता है: test basis से traced, prioritised test conditions। "Redemption के लिए minimum points balance" जैसी condition बताती है कि क्या टेस्ट करना है, लेकिन अभी यह नहीं कि किन values और किन expected results के साथ।

ISTQB Foundation syllabus v4.0 test design को test conditions को test cases और दूसरे testware में विस्तार देने के रूप में बताता है, अक्सर किसी test technique से coverage items पहचानकर। इसके work products हैं:

  • Coverage items: हर test condition से निकली गिनने लायक चीज़ें, जिन्हें test cases को exercise करना है।
  • Prioritised test cases: preconditions, inputs, actions, expected results और postconditions।
  • Test charters, उन conditions के लिए जो scripted test cases की जगह exploratory testing से cover होंगी: charter बताता है कि क्या explore करना है और क्यों, बिना तय steps के।
  • Test data requirements: tests को कौन-सा data चाहिए, किस state में।
  • Test environment requirements: configuration, जुड़े हुए systems, tools और access।

Coverage items: condition से test case तक का पुल

ISTQB glossary के अनुसार coverage item एक या ज़्यादा test conditions से किसी test technique की मदद से निकाला गया attribute या attributes का combination है। आसान शब्दों में, technique एक व्यापक condition को specific items में बदल देती है, जिनमें से हर एक को कम से कम एक test चाहिए।

इससे design measurable बनता है: coverage उन items की संख्या है जिन्हें कम से कम एक test case ने exercise किया, पहचाने गए कुल items से भाग देकर, प्रतिशत में। Depth भी एक साफ़ फ़ैसला बन जाती है: high-risk condition को मज़बूत technique और ज़्यादा items मिलते हैं, low-risk condition के लिए शायद एक test काफ़ी हो।

हर technique, जिसका test design techniques module में अपना lesson है, अलग items बनाती है:

  • Equivalence partitioning: हर partition, valid हो या invalid; partition values का ऐसा group है जिसके साथ system को एक जैसा व्यवहार करना चाहिए।
  • Boundary value analysis: boundary values, यानी हर ordered partition की सबसे छोटी और सबसे बड़ी value। 2-value BVA में हर boundary value के साथ बगल वाले partition की उसकी सबसे नज़दीकी पड़ोसी value जोड़ी जाती है, इसलिए 500 points की limit से 499 और 500 मिलते हैं।
  • Decision table testing: हर feasible column, यानी conditions का एक combination।
  • State transition testing: coverage criterion के हिसाब से states, valid transitions या सभी transitions।

आज़माएँ: इक्विवैलेंस पार्टीशन जनरेटर आज़माएँ: बाउंड्री वैल्यू एनालिसिस

Worked example: एक condition, चार coverage items, दो test cases

Test basis, एक grocery app की story LOY-9: "कम से कम 500 points वाले members checkout पर उन्हें redeem कर सकते हैं। हर 100 points order से 10.00 SAR कम करते हैं। Points कमाने के 12 महीने बाद expire हो जाते हैं।" Analysis ने condition TCO-1, यानी minimum balance, को high risk माना: यहाँ कोई defect बिना हक़ के discount दे देता है या हक़दार members को रोक देता है।

Equivalence partitioning और 2-value boundary value analysis से चार coverage items मिलते हैं। दो test cases सबको exercise कर देते हैं, क्योंकि हर test case एक साथ एक partition और एक boundary value को छूता है। निचला partition 0 से शुरू होता है, जो सबसे छोटा संभव balance है, इसलिए 0 भी एक boundary value है; analysis ने बिना points वाले members के लिए अलग condition बनाई थी, इसलिए यह design 500 की threshold तक सीमित रहता है।

Points rule के लिए test design: एक condition, दो techniques, चार coverage items, चारों को exercise करने वाले दो test cases, और उन tests के लिए ज़रूरी data और environment।
  1. 1Test conditionTest analysis से input: क्या टेस्ट करना हैTCO-1 Points redeem करने का minimum balance · risk: high
  2. 2Test techniquesEquivalence partitioning और 2-value boundary value analysis, risk के हिसाब से चुनी गईं
  3. 34 coverage itemsPartitions: 500 से कम, 500 या ज़्यादा · boundary values: 499, 500
  4. 42 test cases4 में से 4 coverage items exercised: 100%TC-11: 499 points, redeem नहीं · TC-12: 500 points, 50.00 SAR की छूट
    साथ-साथ design
    • 5Data और environment requirementsठीक 499 और 500 points वाले members; loyalty service या stub

चरण 2–4 के दौरान Test design: कैसे टेस्ट करें

इसके बाद:फिर test implementation data बनाता है, environment तैयार करता है और test procedures जोड़ता है

  • Test data requirements: ठीक 499 और ठीक 500 points वाले members, सभी points पिछले 12 महीनों में कमाए हुए ताकि expiry बीच में न आए, और 120.00 SAR total वाली cart।
  • Test environment requirements: जुड़ी हुई loyalty service, या दिया गया balance लौटाने वाला stub, और balances set करने का तरीका, जैसे admin screen या seed script।
  • Design से उठे सवाल: 500 से कम balance पर redeem option छिपता है या disabled होता है, और कौन-सा message आता है? क्या member 550 points redeem कर सकता है, या सिर्फ़ 100 के multiples? Discount order total से ज़्यादा हो तो क्या होगा?
Condition   TCO-1  Points redeem करने के लिए minimum balance   (risk: high)
Techniques  equivalence partitioning + 2-value boundary value analysis

Coverage item                            Exercised by
CI-1  partition: balance 500 से कम        TC-11
CI-2  partition: balance 500 या ज़्यादा    TC-12
CI-3  boundary value 499                 TC-11
CI-4  boundary value 500                 TC-12

TC-11  499 points वाला member, order total 120.00, payment page खोलता है
       Expected: points redeem नहीं हो सकते, total 120.00 ही रहता है
TC-12  500 points वाला member सारे 500 points redeem करता है, order total 120.00
       Expected: 50.00 SAR की छूट, total 70.00, balance से 500 points कटते हैं

Coverage: 4 में से 4 coverage items = 100%

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

Data और environment अभी design करें, बाद में बनाएँ

Test design बताता है कि tests को क्या चाहिए; अगली activity, test implementation, उसे बनाती है। ये ज़रूरतें अभी लिख लेने से data समय पर तैयार होता है और environments समय पर माँगे जाते हैं, बजाय इसके कि execution के पहले दिन वे blocked tests के रूप में सामने आएँ।

Test data requirement records और उनकी state बताती है ("ठीक 499 points वाला member, सभी पिछले 12 महीनों में कमाए हुए"), कोई user id नहीं। Test environment requirement connections और configuration बताती है: third parties के sandboxes या stubs, feature flags, language और time zone, हर role के लिए account, और date set करने जैसे controls।

ISO/IEC/IEEE 29119-2 test design और implementation को एक combined process के रूप में बताता है। इसका 2021 edition test coverage items को test conditions से नहीं, बल्कि एक test model से निकालता है, जैसे partitions का set या state diagram, और फिर test cases और test procedures derive करता है। ISTQB दोनों activities को अलग रखता है; कई teams दोनों एक ही बैठक में कर लेती हैं।

आज़माएँ: टेस्ट डेटा फ़ैक्टरी

आम गलतियाँ

  • Coverage items के बिना requirement से सीधे test cases पर पहुँच जाना, जिससे कोई नहीं बता सकता कि set पूरा है या नहीं।
  • एक ही coverage item के लिए कई test cases, जैसे 600 और 2,000 points के बीच पाँच balances, जबकि 499 और 500 का कोई test नहीं।
  • "Discount सही लगा" जैसे अस्पष्ट expected results, test basis की values की जगह: 50.00 SAR की छूट, total 70.00।
  • Data और environment की ज़रूरतें तब तक अनकही छोड़ना जब तक execution में पता न चले कि ठीक 499 points वाला कोई member है ही नहीं।
  • Test condition की id के बिना test cases, जिससे requirement बदलने पर प्रभावित tests trace नहीं हो पाते।
  • हर condition को एक जैसी depth देना, बजाय सबसे ज़्यादा coverage items वहाँ लगाने के जहाँ failure सबसे महँगी पड़ेगी।

QA का नज़रिया

Agile team में test design story-दर-story होता है: refinement के दौरान और sprint की शुरुआत में, जैसे ही acceptance criteria स्थिर हों। Tester expected results और खुले सवाल product owner के साथ, technical limits और data या clock set करने के तरीके developers के साथ तय करता है, और design review के लिए दूसरे tester से कहता है।

हर test condition के लिए technique, coverage items और उन्हें exercise करने वाले test cases record करें, हर test case पर condition की id के साथ, ताकि requirement बदलने पर भी traceability बनी रहे। Data और environment requirements तैयार करने वालों को सौंपें और हर खुले सवाल का owner तय करें। Test implementation इसी record से शुरू होता है।

अभ्यास

Clinic appointment rules के लिए tests design करें

आपका काम

यह exercise टेस्ट एनालिसिस वाले lesson की clinic story US-57 को आगे बढ़ाती है। Product owner ने AC2 और AC5 के सवालों का जवाब नीचे के दो rules के रूप में दिया है; क्योंकि देर से cancel करने पर अब patient को पैसे देने पड़ते हैं, condition C7 की risk rating medium से high कर दी गई है। C3 और C7 के coverage items पहचानें, सबको exercise करने वाला सबसे छोटा test case set लिखें, और लिखें कि इन tests को क्या चाहिए।

Booking window पूरे दिनों में गिनें और समय minute तक compare करें। बाकी हर assumption को सवाल के रूप में लिखें।

सामग्री
Story US-57  Clinic appointment online बुक करना
AC2 और AC5 के सवालों पर product owner के जवाब:
Rule 1  Patient आज से 1 से 30 दिन आगे तक का appointment book कर सकता है।
Rule 2  Appointment से 24 घंटे पहले तक cancel करना free है;
        उसके बाद cancel करने पर 50.00 SAR fee लगती है।

Test analysis से मिली test conditions
C3  Booking window: patient कितने दिन पहले book कर सकता है     (risk: medium)
C7  Cancellation fee, appointment शुरू होने से पहले बचे समय पर निर्भर  (risk: high)
चरण
  1. C3 के लिए "कितने दिन पहले" के partitions और 2-value boundary values लिखें।
  2. C7 के लिए "appointment से पहले बचा समय" के साथ यही करें।
  3. Input, expected result और हर case जिन coverage items को exercise करता है, उनके साथ minimum test cases लिखें; coverage निकालें।
  4. Data और environment requirements और product owner के लिए सवाल लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

C3, सात coverage items। Partitions: 0 दिन पहले या कम, यानी आज या कोई पिछली तारीख़ (invalid, CI-1); 1 से 30 दिन (valid, CI-2); 31 या ज़्यादा (invalid, CI-3)। Boundary values: 0, 1, 30 और 31 (CI-4 से CI-7)। चार test cases: आज, reject (CI-1, CI-4); कल, booked (CI-2, CI-5); 30 दिन आगे, booked (CI-2, CI-6); 31 दिन आगे, reject (CI-3, CI-7)। Coverage: 7 में से 7 = 100%।

C7, चार coverage items। Partitions: start से 24 घंटे या ज़्यादा पहले, free (CI-8); 24 घंटे से कम, fee (CI-9)। Boundary values: start से 24:00 और 23:59 पहले (CI-10, CI-11)। दो test cases, दोनों high priority: ठीक 24 घंटे पहले cancel, कोई fee नहीं (CI-8, CI-10); 23 घंटे 59 मिनट पहले cancel, 50.00 SAR fee लगती है (CI-9, CI-11)। Coverage: 4 में से 4 = 100%। Fee partition का दूसरा सिरा, यानी appointment का start time, नीचे के आख़िरी सवाल के जवाब पर निर्भर है।

Data: payment sandbox में payment method वाला patient; ऐसा doctor जिसके free slots आज, कल, और 30 और 31 दिन आगे हों (दिन 31 पर slot न हो तो reject होना कुछ साबित नहीं करता); तय start time वाले appointments। Environment: production का time zone, controllable clock या 24 घंटे की boundary को minute तक पकड़ने का कोई और तरीका, और जुड़ा हुआ payment sandbox।

सवाल: क्या ठीक 24 घंटे पहले cancel करना free है? समय minute तक compare होता है या second तक? किसका time zone लागू होता है? क्या window में आज दिन 0 है? क्या patient start के बाद cancel कर सकता है, और किस कीमत पर?

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

Test analysis और test design में क्या फ़र्क है?

Test analysis "क्या टेस्ट करें" का जवाब देता है: यह test basis को evaluate करके prioritised test conditions बनाता है। Test design "कैसे टेस्ट करें" का जवाब देता है: यह उन conditions को coverage items, test cases और data व environment requirements में बदलता है। छोटी teams में अक्सर एक ही व्यक्ति दोनों एक बैठक में कर लेता है, पर दोनों सवालों को अलग रखने से पता चलता है कि कहीं कोई छूट तो नहीं गया।

क्या coverage item और test case एक ही हैं?

नहीं। Coverage item वह चीज़ है जिसे exercise होना है; test case वह है जो उसे exercise करता है। एक test case कई items cover कर सकता है: worked example में 500 points वाला test case "500 या ज़्यादा" partition और boundary value 500 दोनों को exercise करता है। Coverage items को गिनती है, इसलिए उन्हीं items को छूने वाले और test cases जोड़ने से coverage नहीं बढ़ती।

क्या हमेशा detailed, step-by-step test cases लिखने ज़रूरी हैं?

नहीं। Detail का स्तर test plan में तय context पर निर्भर है। Regulated काम, automation और नए team members को concrete values वाले low-level test cases चाहिए; एक अनुभवी team high-level test cases रख सकती है, या किसी condition को exploratory test charter से cover कर सकती है, जिसे ISTQB syllabus भी test design का work product मानता है।

क्या 100% coverage का मतलब है कि feature में कोई defect नहीं?

नहीं। इसका मतलब सिर्फ़ इतना है कि आपके पहचाने हर coverage item को कम से कम एक test ने exercise किया। Defects फिर भी उन conditions में छिपे हो सकते हैं जो analysis से छूट गईं, उन items में जो चुनी गई technique बनाती ही नहीं, या ऐसे combinations में जिन्हें किसी ने design नहीं किया। Coverage बताती है कि क्या टेस्ट हुआ, यह नहीं कि software सही है।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021टेस्ट प्रक्रिया मॉडल: संगठनात्मक, टेस्ट प्रबंधन और dynamic टेस्ट प्रक्रियाएँ, उनकी गतिविधियों और परिणामों के साथ।
टूल्स

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

Requirements → टेस्ट केस

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

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

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

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

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

टेस्ट डेटा फ़ैक्टरी

सिंथेटिक टेस्ट डेटा की एक ही जगह पर फ़ैक्टरी: users, customers, companies, पते, संख्याएँ, तारीख़ें और स्ट्रिंग — JSON, CSV, SQL या XML में।

टेस्ट डेटा

और गहराई से

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

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

इस topic से पहले