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

टेस्ट टेक्निक्स का ओवरव्यू

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

Test technique एक systematic तरीका है जिससे आप तय करते हैं कि क्या टेस्ट करना है और कैसे। आप इसे जानकारी के किसी source पर लागू करते हैं, जैसे requirement या code, और यह test conditions तय करने, coverage items पहचानने और test data चुनने में मदद करती है। ISTQB Foundation syllabus (v4.0) techniques को इस आधार पर तीन categories में बाँटता है कि वे किस पर टिकी हैं: black-box techniques specified behaviour पर, white-box techniques code की internal structure पर, और experience-based techniques tester के knowledge और skill पर।

एक sign-up form लीजिए जिसका age field 18 से 65 स्वीकार करता है। Equivalence partitioning, जो एक black-box technique है, हर age group के लिए एक test देती है। Developer की branch coverage report, जो एक white-box measure है, दिखाती है कि खाली age field वाला code path कभी चला ही नहीं। एक अनुभवी tester age के बाद एक space लगाकर paste करता है, क्योंकि इसी से पहले एक मिलता-जुलता form टूटा था। तीन categories, एक ही field को देखने के तीन अलग नज़रिए: हर एक ऐसे defects पकड़ सकती है जो बाकी दो से छूट जाते हैं।

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

Exhaustive testing असंभव है, जैसा seven principles कहते हैं, इसलिए हर test suite एक sample है। Technique के बिना यह sample आदत पर चलता है: फिर से happy path, दिमाग़ में सबसे पहले आने वाली values, और defects की पूरी categories जिन्हें कोई आज़माता ही नहीं। Technique sample को सोचा-समझा बनाती है: वह बताती है कि कौन-सी values चुननी हैं और क्यों।

Techniques आपके काम को reviewable भी बनाती हैं। "मैंने ज़रूरी चीज़ें टेस्ट कर लीं" जाँचा नहीं जा सकता; "fee rule का हर partition और हर boundary, और order status का हर valid transition" जाँचा जा सकता है। Reviewers release के बाद नहीं, पहले ही gaps पकड़ सकते हैं।

Black-box, white-box और experience-based techniques

Black-box techniques, जिन्हें specification-based भी कहते हैं, test object के specified behaviour से tests निकालती हैं: requirements, user stories, business rules, API contract। ये नहीं देखतीं कि software कैसे बना है, इसलिए developers के code refactor करने पर भी tests valid रहते हैं।

White-box techniques, जिन्हें structure-based भी कहते हैं, code की internal structure, जैसे उसके statements और branches, से tests निकालती हैं और नापती हैं कि tests ने उसका कितना हिस्सा चलाया। इनके लिए design या code का मौजूद होना ज़रूरी है। जो requirement कभी implement ही नहीं हुई, उसका cover करने लायक code ही नहीं होता, इसलिए white-box testing ऐसा defect of omission नहीं पकड़ सकती।

Experience-based techniques tester के domain knowledge, पुराने defects और software आम तौर पर कैसे fail होता है, इसकी समझ का इस्तेमाल करती हैं। ये ऐसे defects पकड़ती हैं जो systematic techniques से छूट जाते हैं, लेकिन काफ़ी हद तक व्यक्ति पर निर्भर करती हैं, इसलिए ये बाकी दो categories की पूरक हैं, उनका विकल्प नहीं।

  • Black-box: equivalence partitioning, boundary value analysis, decision table testing और state transition testing (Foundation syllabus की चार techniques), और इस module में आगे use case, pairwise और combinatorial testing।
  • White-box: statement testing और branch testing, जिनमें tests इस तरह design किए जाते हैं कि वे code के executable statements या branches चलाएँ, और चले हुए हिस्से को coverage के रूप में नापा जाता है; condition और path coverage इस module में आगे आते हैं।
  • Experience-based: error guessing (पहले जो fail हुआ उसके आधार पर संभावित गलतियों और defects का अनुमान लगाना), exploratory testing (product के बारे में सीखते हुए एक ही समय में tests design, execute और evaluate करना, अक्सर एक time-boxed session में जिसकी दिशा test charter तय करता है, यानी एक छोटा statement कि क्या explore करना है और क्यों) और checklist-based testing (experience से बनी checklist की test conditions को टेस्ट करना)।

Collaboration-based approaches: defects सिर्फ़ ढूँढें नहीं, रोकें

ऊपर की techniques का मकसद defects detect करना है। Syllabus collaboration-based test approaches भी जोड़ता है, जिनका मकसद code लिखे जाने से पहले बातचीत के ज़रिए defects से बचना भी है: collaborative user story writing, acceptance criteria और acceptance test-driven development (ATDD), जो user stories और acceptance criteria वाले lessons में आ चुके हैं। ये business और developers के साथ काम करने का तरीका हैं, techniques की चौथी category नहीं।

फिर भी इन बातचीतों के अंदर असली काम techniques ही करती हैं। जब team यह example लिखती है कि "300 SAR या उससे ज़्यादा के orders की delivery free है", तो tester 299.99 और 300.00 के बारे में पूछता है: code की एक line लिखे जाने से पहले ही boundary value analysis।

आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर

Technique कैसे चुनें

पहले पूछें: आप tests किस चीज़ से निकाल रहे हैं? Refinement में चल रही story को collaboration चाहिए। Specified behaviour को black-box technique चाहिए, जो rule के shape से चुनी जाती है: values के groups के लिए equivalence partitioning, और values ordered हों, जैसे किसी range में, तो साथ में boundary value analysis; conditions के combinations के लिए decision table; पहले क्या हुआ उस पर निर्भर behaviour के लिए state transition testing; और कई independent parameters के लिए pairwise testing। जिस code को नापना है उसके लिए white-box techniques; कमज़ोर documentation या नए area के लिए exploratory testing और error guessing।

Technique का चुनाव: refinement वाली story को collaboration चाहिए, specified rule का shape black-box technique चुनता है, code के लिए white-box और कमज़ोर documentation के लिए experience-based testing। वैचारिक मॉडल
प्रश्न 1: आप tests किस चीज़ से निकाल रहे हैं?Test basis से शुरू करें, फिर rule का shape देखें

  • उत्तर: Refinement में चल रही story

    परिणाम: User stories, acceptance criteria, ATDDDefects रोकने के लिए coding से पहले examples तय करेंCollaboration-based

  • उत्तर: Specified behaviour

    प्रश्न 2: Rule का shape क्या है?

    • उत्तर: Ranges या values के groups

      परिणाम: Equivalence partitioning और BVACoverage items: partitions, और values ordered हों तो boundary valuesBlack-box

    • उत्तर: Conditions के combinations

      परिणाम: Decision table testingCoverage items: संभव columnsBlack-box

    • उत्तर: पहले क्या हुआ, उस पर निर्भर

      परिणाम: State transition testingCoverage items: states या transitionsBlack-box

    • उत्तर: कई independent parameters

      परिणाम: Pairwise testingCoverage items: parameter values के pairsBlack-box

  • उत्तर: Code और उसकी structure

    परिणाम: Statement और branch testingज़्यादातर developers, component testing में; missing requirements नहीं पकड़तीWhite-box

  • उत्तर: कमज़ोर documentation या नया area

    परिणाम: Exploratory testing, error guessing, checklistsSkill पर निर्भर; charter और notes इसे reviewable बनाते हैंExperience-based

यह शुरुआत है, नियम नहीं: ज़्यादातर features को कई techniques चाहिए, और risk तय करता है कि हर एक कितनी rigorous हो।

फिर context को अपना चुनाव adjust करने दें, और कई techniques मिलाने की उम्मीद रखें: ज़्यादातर features में अलग-अलग shape वाले rules होते हैं।

  • Risk: ज़्यादा risk पर ज़्यादा rigorous techniques और मज़बूत coverage, जैसे 3-value BVA, या valid के साथ invalid transitions भी।
  • Test level: developers white-box techniques ज़्यादातर component testing में लगाते हैं; बाकी categories हर level पर काम करती हैं।
  • Test basis: सटीक specification black-box techniques को सहारा देता है; अस्पष्ट specification को पहले बातचीत चाहिए।
  • Constraints: कुछ domains में contracts या regulations techniques या coverage levels तय कर देते हैं, और team के skills और समय तय करते हैं कि क्या realistic है।

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

Worked example: return request के लिए techniques

एक online shop return requests जोड़ रहा है। हर rule को उसके shape के हिसाब से technique मिलती है, और plan एक बातचीत से शुरू होता है।

  • Refinement (collaboration): "Return 30 दिनों के अंदर माँगा जा सकता है।" Tester पूछता है: delivery से या order से? क्या 30वाँ दिन शामिल है? जवाब acceptance criteria बन जाते हैं।
  • Delivery के बाद 1 से 30 दिन की return window (range): equivalence partitioning और 2-value BVA से 0, 1, 30 और 31 दिन मिलते हैं।
  • Payment type (card या cash on delivery), gift है या नहीं, और item खोला गया या नहीं, इनके हिसाब से refund method (combinations): अधिकतम 2 × 2 × 2 = 8 columns वाली decision table।
  • Return status, जिसमें cancel सिर्फ़ pick-up से पहले हो सकता है (states और events): state transition testing, invalid कोशिशों समेत, जैसे pick-up के बाद cancel करना।
  • नए function में restocking fee (code): developer branch coverage नापता है; tester पूछता है कि कौन-सी branches अभी uncovered हैं।
  • कम documentation वाले नए courier integration से pick-up: charter के साथ exploratory session, और पुराने defects से error guessing, जैसे लंबे Arabic addresses और courier time-outs।

आज़माएँ: डिसीज़न टेबल जनरेटर आज़माएँ: स्टेट ट्रांज़िशन जनरेटर

आम गलतियाँ

  • एक technique को पूरा काम मान लेना, जैसे सिर्फ़ boundary values टेस्ट करके feature को tested कह देना।
  • Rule के shape की बजाय आदत से, या इसलिए कि tool मौजूद है, technique चुनना, उदाहरण के लिए payment methods जैसे unordered options पर boundary values।
  • ऊँची code coverage को इस बात का सबूत मान लेना कि requirements tested हैं; वह उन requirements को नहीं देख सकती जो कभी implement ही नहीं हुईं।
  • Experience-based testing को बिना plan की clicking समझना: charter और notes के बिना कोई नहीं बता सकता कि क्या cover हुआ।
  • यह दर्ज न करना कि कौन-सा test case किस technique से बना, जिससे reviewers coverage नहीं आँक पाते और कोई नहीं जानता कि case क्यों है।

QA का नज़रिया

असली team में यह चुनाव दो बार होता है। Refinement में आप हर rule का shape पहचानते हैं और वे सवाल पूछते हैं जो उसे testable बनाते हैं। Test design में आप हर rule के लिए technique चुनते हैं, उसे coverage items के साथ test case या design notes में दर्ज करते हैं, और उसकी rigour को test plan में तय risk के हिसाब से रखते हैं।

Developers के साथ काम बाँटें: component level पर white-box coverage उनकी ज़िम्मेदारी है, और आप high-risk code की coverage report देखने को माँगते हैं। नए या बदले हुए areas पर exploratory sessions के लिए समय रखें। जब कोई पूछे "क्या यह काफ़ी tested है?", तो जवाब techniques, coverage और residual risk से दें, अंदाज़े से नहीं।

अभ्यास

Parking app के लिए techniques चुनें

आपका काम

नीचे एक शहर के parking app के पाँच rules हैं। हर rule के लिए उसका shape, एक technique या approach और उसकी category, और पहले coverage items या test values लिखें। फिर refinement के लिए अपने सवाल लिखें।

सामग्री
PARK-12  Story: app से street parking का भुगतान
Rule 1: एक parking session 15 से 240 पूरे मिनट तक चलता है।
Rule 2: Price zone (A, B या C), driver के पास resident permit है या नहीं,
        और car electric है या नहीं, इन पर निर्भर है।
Rule 3: Session पहले Booked, फिर Active होता है; Ended (driver ने रोका)
        या Expired पर ख़त्म होता है। Booked session Cancelled हो सकता है।
        Active session को अधिकतम दो बार extend किया जा सकता है।
Rule 4: App Android और iOS पर, Arabic और English में चलता है, और
        card, digital wallet या account balance स्वीकार करता है।
Rule 5: Expiry से पहले के नए SMS reminder की अभी कोई specification नहीं है।
चरण
  1. हर rule का shape पहचानें: range, combinations, states, independent parameters, या कोई specification नहीं।
  2. हर rule के लिए technique या approach चुनें और उसकी category लिखें।
  3. पहले coverage items या test values लिखें।
  4. Refinement meeting के लिए अपने सवाल लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Rule 1, range: equivalence partitioning और BVA (black-box)। 14, 15, 240 और 241 मिनट टेस्ट करें, साथ में एक typical value जैसे 60।

Rule 2, conditions के combinations: decision table testing (black-box): अधिकतम 3 × 2 × 2 = 12 columns, और उन columns को merge करने के बाद कम, जिनमें कोई condition नतीजा नहीं बदलती।

Rule 3, states और events: state transition testing (black-box)। पाँचों valid transitions cover करें, जिनमें Active session को extend करना भी है, और invalid कोशिशें, जैसे तीसरा extension या Expired session को extend करना।

Rule 4, independent parameters: pairwise testing (black-box)। सारे 2 × 2 × 3 = 12 combinations की जगह छह tests भी values के हर pair को cover करते हैं।

Rule 5, कोई specification नहीं: experience-based। Charter के साथ time-boxed exploratory session, और error guessing, जैसे session extend होने के बाद भेजा गया reminder। साथ ही product owner से acceptance criteria माँगें।

White-box: किसी rule के लिए आपको white-box tests design नहीं करने हैं; developers से price calculation की branch coverage माँगें। सवाल: क्या 240 मिनट एक booking की limit है या extensions मिलाकर? क्या resident permit हर zone में लागू होता है? Expiry किसकी घड़ी तय करती है, phone की या server की?

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

सबसे अच्छी test technique कौन-सी है?

आम तौर पर कोई नहीं। हर technique एक तरह के rule और एक तरह के defect को निशाना बनाती है: boundary value analysis off-by-one comparisons पकड़ती है, decision tables भूले हुए combinations, state transition testing missing या illegal transitions, और exploratory testing वे problems जिन्हें किसी ने specify ही नहीं किया। Problem के shape और risk के हिसाब से चुनें, और techniques को मिलाएँ।

अगर developers unit tests लिखते हैं, तो क्या tester को white-box techniques की ज़रूरत है?

हो सकता है आप ख़ुद कम ही white-box tests design करें, लेकिन उन्हें समझना ज़रूरी है: coverage report पढ़ने के लिए, यह पूछने के लिए कि कौन-सी risky branches untested हैं, और यह जानने के लिए कि 100% branch coverage उन requirements के बारे में कुछ नहीं कहती जो कभी implement ही नहीं हुईं। Automation roles वाले testers अक्सर component tests भी लिखते हैं।

क्या exploratory testing और ad hoc testing एक ही हैं?

नहीं। Ad hoc testing informal होती है: उसमें न test analysis होता है न test design, और आम तौर पर वह कोई record नहीं छोड़ती। Exploratory testing एक ही समय में tests design, execute और evaluate करती है, लेकिन यह structured हो सकती है: charter mission तय करता है, time box session को सीमित करता है, और notes दर्ज करते हैं कि क्या cover हुआ और क्या मिला। Session-based test management इसी structure पर बनता है।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009एजाइल टेस्टिंग क्वाड्रेंट और टेस्टर डिलीवरी टीम के भीतर कैसे काम करते हैं — "सही परत पर टेस्टिंग" का आधार।
टूल्स

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

डिसीज़न टेबल जनरेटर

conditions और actions से decision table बनाएँ, सभी rule संयोजन जनरेट करें और असंभव संयोजनों को समेट दें।

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

स्टेट ट्रांज़िशन जनरेटर

states और events परिभाषित करें, फिर transition तालिका, वैध/अमान्य transition टेस्ट और 0-switch/1-switch coverage जनरेट करें।

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

और गहराई से

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

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