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

डिसीज़न टेबल टेस्टिंग

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

Decision table testing एक black-box test design technique है, उन rules के लिए जिनमें conditions का combination नतीजा तय करता है। Conditions और actions rows बनाते हैं; हर column एक decision rule है, यानी condition values का एक combination और उसके actions। "Saved beneficiary को transfer तुरंत होता है; new beneficiary को 5,000.00 SAR से ज़्यादा के transfer के लिए one-time password चाहिए" में दो conditions हैं, यानी चार columns, और यह वाक्य उनमें से एक के बारे में कुछ नहीं कहता: new beneficiary को छोटा transfer।

Business rules वाले lesson और उसकी T, F और X वाली table के आगे, यह lesson पूरा notation, minimised tables, coverage, और भूले हुए rules पकड़ने वाली एक गिनती जोड़ता है।

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

कई conditions वाले rules के defects उस एक combination में छिपे होते हैं जिस पर किसी ने बात नहीं की: frozen account जो अब भी saved beneficiary को पैसे भेज सकता है, या वह customer जो requirement के दो वाक्यों के बीच गिर जाता है और उसे वही मिलता है जो code संयोग से करता है। Typical cases दोनों हालात में pass हो जाते हैं।

Decision table हर combination को दिखने और गिनने लायक बनाती है। Requirements review में बनी table gaps और contradictions को production के defects की जगह product owner के लिए सवाल बना देती है।

Conditions, actions और decision rules

Condition rows में वह होता है जिस पर rule निर्भर है; action rows में वह जो system को करना चाहिए। Full table में condition values के हर combination का एक column होता है: तीन true/false conditions से 2 × 2 × 2 = 8 columns बनते हैं।

अगर हर condition सिर्फ़ true या false हो, तो table limited-entry है। Extended-entry table में कोई condition, या action, कई values ले सकती है, जैसे ranges, equivalence partitions या "tier: standard, silver, gold" जैसी अलग-अलग values। तब columns की संख्या values की संख्याओं का गुणनफल होती है: एक तीन-value और दो true/false conditions से 3 × 2 × 2 = 12। ISTQB Foundation syllabus यह notation इस्तेमाल करता है:

  • T: condition सच है; F: सच नहीं है। Syllabus दूसरे notations की भी इजाज़त देता है, और कुछ tools Y और N लिखते हैं।
  • –: इस column में condition बेअसर है; कोई भी value वही actions देती है। इसे अक्सर "don’t care" कहा जाता है और hyphen, -, से लिखा जाता है।
  • N/A: इस rule में condition infeasible है, जैसे customer cash से pay करे तो "card expired"।
  • X: action होना चाहिए; खाली जगह: नहीं होना चाहिए।

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

Worked example: missing और conflicting rules खोजना

Mobile banking app की requirement TR-07: "S1. Saved beneficiary को transfers तुरंत process होते हैं। S2. New beneficiary को 5,000.00 SAR से ज़्यादा के transfers तब process होते हैं जब customer one-time password (OTP) डाल देता है। S3. Frozen account से transfers reject होते हैं।"

तीन conditions (account frozen, beneficiary saved, amount 5,000.00 SAR से ज़्यादा), तीन actions (reject, OTP के बाद process, तुरंत process)। क्या ये वाक्य हर combination को ठीक एक बार cover करते हैं? चार steps बताते हैं।

  • गिनें: हर वाक्य को column के रूप में लिखें और जिस condition का वह ज़िक्र नहीं करता वहाँ – लगाएँ, जैसा नीचे की table में है। True/false conditions में एक – यानी 2 combinations, दो यानी 4: S1 और S3 चार-चार, S2 दो, कुल 10, जबकि combinations सिर्फ़ 8 हैं। 8 से ज़्यादा का मतलब कम से कम एक overlap, 8 से कम का मतलब कम से कम एक gap; overlap तब conflict है जब उसके वाक्य अलग-अलग actions दें।
  • फैलाएँ: total मिल जाना कुछ साबित नहीं करता, क्योंकि gap और overlap एक-दूसरे को काट सकते हैं, इसलिए full table के हर column पर लागू होने वाले वाक्य चिह्नित करें। Columns 1 से 3, यानी saved beneficiary या 5,000.00 SAR से ज़्यादा amount वाला frozen account, conflicts हैं: S3 reject करता है, S1 या S2 process। Column 8, यानी active account से new beneficiary को 5,000.00 SAR तक का transfer, gap है।
  • पूछें: अंदाज़ा लगाने की बजाय दोनों product owner के पास ले जाएँ। जवाब: freeze हर transfer रोकता है, और new beneficiary को 5,000.00 SAR तक का transfer तुरंत process होता है। इन्हें requirement में दर्ज करें।
  • Table से आगे देखें: यह सिर्फ़ आपकी लिखी conditions जाँचती है, इसलिए missing conditions (daily limit, दूसरी currency) और missing actions (reject के बाद दिखने वाला message) के बारे में पूछें।
TR-07 as written: one column per sentence

      Frozen  Saved  > 5,000.00 SAR  Action               Stands for
S1    –       T      –               process immediately  4 combinations
S2    –       F      T               process after OTP    2 combinations
S3    T       –      –               reject               4 combinations
                                     Total                10, but only 8 exist
Transfer rule TR-07 की 8 combinations से जाँच: columns 1 से 3 में दो वाक्य अलग-अलग actions देते हैं, column 8 पर कोई वाक्य लागू नहीं होता, और product owner के जवाब चारों को तय करते हैं।
Decision table columnAccount frozenBeneficiary saved5,000.00 SAR से ज़्यादालिखा हुआ TR-07Product owner के जवाबों के बाद
Column 1TTTS1 + S3conflict: तुरंत process या rejectसावधानीrejectproduct owner का जवाब
Column 2TTFS1 + S3conflict: तुरंत process या rejectसावधानीrejectproduct owner का जवाब
Column 3TFTS2 + S3conflict: OTP के बाद process या rejectसावधानीrejectproduct owner का जवाब
Column 4TFFS3rejectपासreject
Column 5FTTS1तुरंत processपासतुरंत process
Column 6FTFS1तुरंत processपासतुरंत process
Column 7FFTS2OTP के बाद processपासOTP के बाद process
Column 8FFFकोई वाक्य नहींgapफ़ेलतुरंत processproduct owner का जवाब
  • फ़ेलGap: कोई वाक्य नहीं बताता कि क्या होगा
  • सावधानीConflict: दो वाक्य अलग-अलग actions देते हैं
  • Product owner के जवाब से तय

यहाँ हर row पूरी decision table का एक column है। T: condition सच है; F: सच नहीं है। S1, S2 और S3, TR-07 के वाक्य हैं।

Full, simplified और minimised tables

ISTQB syllabus table छोटी करने के दो तरीके बताता है। Simplified table उन columns को हटा देती है जिनका conditions combination infeasible हो: "5,000.00 SAR से ज़्यादा" और "20,000.00 SAR से ज़्यादा" conditions के साथ कोई amount 5,000.00 से ज़्यादा हुए बिना 20,000.00 से ज़्यादा नहीं हो सकता, इसलिए पहली condition में F और दूसरी में T वाला हर column हटा दिया जाता है। Minimised table, जिसे कुछ books और tools collapsed table कहते हैं, उन columns को merge करती है जिनके actions एक जैसे हों और जो ठीक एक condition में अलग हों; वह condition – बन जाती है।

Clarified TR-07 में columns 1 से 4 सब reject करते हैं और दो steps में R1 (T, –, –) में merge होते हैं; columns 5 और 6 मिलकर R2 (F, T, –) बनते हैं; columns 7 और 8, R3 और R4 के रूप में रहते हैं। उसी गिनती से जाँचें: 4 + 2 + 1 + 1 = 8। दूसरे merges भी संभव हैं, जैसे column 8 को column 6 के साथ। सिर्फ़ ऐसे सही merges से बना हर नतीजा valid है; गिनती एक तेज़ जाँच है, सबूत नहीं।

Full table (TR-07 with the product owner’s answers)
                       1  2  3  4  5  6  7  8
Account frozen         T  T  T  T  F  F  F  F
Beneficiary saved      T  T  F  F  T  T  F  F
Amount > 5,000.00 SAR  T  F  T  F  T  F  T  F
Reject                 X  X  X  X
Process after OTP                        X
Process immediately                X  X     X

Minimised table        R1  R2  R3  R4
Account frozen         T   F   F   F
Beneficiary saved      –   T   F   F
Amount > 5,000.00 SAR  –   –   T   F
Reject                 X
Process after OTP              X
Process immediately        X       X
Stands for             4   2   1   1   = 8 combinations

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

Coverage और test values चुनना

Coverage items वे columns हैं जिनमें conditions के feasible combinations हों, और coverage उनमें से उन columns का हिस्सा है जिन्हें आपके tests exercise करते हैं। नीचे के चार test cases, हर minimised column के लिए एक, minimised table की 100% coverage देते हैं, लेकिन full table के 8 में से सिर्फ़ 4 columns, यानी 50%, इसलिए हमेशा बताएँ कि आपने किस table पर नापा।

Minimised table मानकर चलती है कि code सच में हर – condition को नज़रअंदाज़ करता है। अगर code freeze से पहले amount जाँचे, तो new beneficiary को 6,000.00 SAR भेजने वाले frozen account से OTP माँगा जाएगा, जिसे सिर्फ़ full table के column 3 का test पकड़ता है। पैसे भेजने वाले rules के लिए सभी 8 columns पर विचार करें।

Test में – को भी एक ठोस value चाहिए: वह value चुनें जो condition के असल में असरदार होने पर action बदल देती। R1 saved beneficiary लेता है, क्योंकि पैसे भेजता frozen account सबसे बुरा failure है; R2 बड़ा amount लेता है, अगर हर बड़े transfer पर OTP माँगा जाता हो। Ranges boundary पर टेस्ट होती हैं, जैसा boundary value analysis में: R3 के लिए 5,000.01, R4 के लिए 5,000.00।

Test  Rule  Account  Beneficiary  Amount (SAR)  Expected result
TC-1  R1    frozen   saved        6,000.00      rejected, no money leaves the account
TC-2  R2    active   saved        6,000.00      processed immediately, no OTP asked
TC-3  R3    active   new          5,000.01      OTP asked, processed after a valid OTP
TC-4  R4    active   new          5,000.00      processed immediately, no OTP asked

आज़माएँ: बाउंड्री वैल्यू जनरेटर

आम गलतियाँ

  • सिर्फ़ उन combinations के columns लिखना जिनका requirement में ज़िक्र है।
  • जहाँ requirement चुप हो वहाँ – लगा देना। चुप्पी product owner के लिए सवाल है, इस बात का सबूत नहीं कि condition बेअसर है।
  • ऐसे columns merge करना जिनके actions अलग हों या जो एक से ज़्यादा conditions में अलग हों।
  • सिर्फ़ columns के total पर भरोसा करना: gap और overlap एक-दूसरे को काट सकते हैं।
  • यह बताए बिना "100% coverage" report करना कि full table नापी गई या minimised।
  • जब नतीजा events के क्रम पर निर्भर हो, जैसे तीन failed sign-ins के बाद lockout, तब decision table इस्तेमाल करना; वहाँ state transition testing चाहिए।

QA का नज़रिया

Decision tables सबसे ज़्यादा फ़ायदा refinement और requirements review में देती हैं। जब कोई story conditions को "और", "या", "जब तक नहीं" या "सिवाय" से जोड़े, तो meeting में ही table का sketch बनाएँ, columns गिनें और हर gap व overlap तुरंत उठाएँ। जवाब requirement में दर्ज करें, और table को rule version के label के साथ test cases के पास रखें।

Minimised table पर भरोसा करने से पहले developer से पूछें कि conditions किस क्रम में evaluate होती हैं। हर test case को उसके column से trace करें, coverage "minimised table के 4 में से 4 columns" की तरह report करें, और rule बदलने पर पहले table update करें: एक नई true/false condition full table को दोगुना कर देती है।

अभ्यास

Cancellation rule में gaps और conflicts जाँचें

आपका काम

एक food-delivery app का cancellation rule नीचे है। उसकी decision table बनाएँ, gaps और conflicts खोजें और product owner के लिए सवाल लिखें। फिर स्पष्ट की गई table को minimise करें और उसकी 100% coverage के लिए test cases गिनें।

सामग्री
CR-2  Order cancellation
1. जिन orders को restaurant ने अभी accept नहीं किया, उन्हें full refund
   के साथ cancel किया जा सकता है।
2. Cash से paid accepted orders cancel नहीं किए जा सकते।
3. Card से payment करने वाले subscribers को cancel करने पर 50% refund मिलता है।
चरण
  1. Conditions और actions की list बनाएँ।
  2. हर वाक्य को – entries वाले column के रूप में लिखें; combinations जोड़ें।
  3. Full table तक फैलाएँ; हर column पर लागू होने वाले वाक्य चिह्नित करें।
  4. सवाल लिखें, संभावित जवाब मानें, minimise करें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Conditions: accepted, card से payment, subscriber। Actions: full refund, 50% refund, refused। वाक्य 1 है (F, –, –), यानी 4 combinations; वाक्य 2 (T, F, –), यानी 2; वाक्य 3 (–, T, T), यानी 2। Total 8 है: पूरा लगता है, पर है नहीं।

Full table, T पहले और F बाद में, पहली condition सबसे धीरे बदलती है: column 1 (T, T, T) में 50% refund; column 2 (T, T, F), यानी non-subscriber का card से paid accepted order, किसी वाक्य से match नहीं करता: gap; columns 3 और 4 refused; column 5 (F, T, T) पर वाक्य 1 और 3 दोनों लागू: conflict; columns 6 से 8 में full refund।

सवाल: card से paid accepted order cancel करने पर non-subscriber को क्या मिलेगा? जिस subscriber ने card से payment किया और जिसका order अभी accept नहीं हुआ, उसे full refund मिलेगा या 50%? Wallets का क्या?

अगर column 2 refused हो और column 5 में full refund, तो minimised table है: (F, –, –) full refund, (T, F, –) refused, (T, T, F) refused, (T, T, T) 50% refund: 4 + 2 + 1 + 1 = 8। चार test cases उसकी 100% coverage देते हैं, full table की 50%।

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

एक decision table के लिए कितनी conditions बहुत ज़्यादा हैं?

कोई तय सीमा नहीं, लेकिन हर true/false condition के साथ full table दोगुनी होती है: 4 conditions से 16 columns, 5 से 32। इतनी बड़ी table बनाने से पहले देखें कि क्या rule स्वतंत्र हिस्सों में बँटता है, जैसे पहले eligibility फिर fee, और हर हिस्से की अपनी छोटी table हो। फिर भी बहुत columns बचें, तो minimised table टेस्ट करें या risk के आधार पर columns चुनें। जब बहुत-से स्वतंत्र parameters हों जिन्हें कोई rule नहीं जोड़ता, तो pairwise testing बेहतर बैठती है।

Full table टेस्ट करूँ या minimised?

Risk कम हो और आपको भरोसा हो कि code हर – condition को नज़रअंदाज़ करता है, तो minimised table काफ़ी है। जब rule पैसे भेजता हो, access या eligibility तय करता हो, या आपको पता हो कि code conditions को table से अलग क्रम में जाँचता है, तब full table टेस्ट करें, या कम से कम वे columns जिनमें गलती की सबसे ज़्यादा संभावना है।

क्या decision tables, equivalence partitioning और boundary value analysis की जगह ले लेती हैं?

नहीं, ये साथ काम करती हैं। Equivalence partitioning हर condition की values देती है, जैसे 5,000.00 SAR तक के amounts और उससे ऊपर। Decision table इन values को rules में जोड़ती है। फिर boundary value analysis हर column के अंदर ठोस amounts चुनती है, जैसे 5,000.00 और 5,000.01।

संदर्भ

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

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

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

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

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

और गहराई से

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

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