कॉम्बिनेटोरियल टेस्टिंग
Combinatorial testing एक black-box test technique है जो कई parameters की values के चुने हुए combinations चलाने के लिए test cases design करती है। हर combination चलाने की बजाय आप एक strength t चुनते हैं: किन्हीं भी t parameters की values का हर combination कम से कम एक test में आता है। पाँच parameters वाले checkout में, जहाँ हर parameter की चार values हैं, 1,024 combinations हैं; 16 tests values के हर pair को cover कर सकते हैं।
Pairwise testing strength 2 वाला combinatorial testing है। यह lesson इसमें strength चुनना, parameters के बीच constraints, classification tree method, और यह जोड़ता है कि pairs कब काफ़ी नहीं होते।
यह क्यों ज़रूरी है
कई failures तभी दिखते हैं जब कुछ ख़ास values मिलती हैं: express delivery, fixed-amount coupon और business account अकेले भी ठीक चलते हैं और किन्हीं भी दो के साथ भी, फिर भी जो business customer fixed-amount coupon के साथ express delivery चुनता है, उससे गलत fee ली जाती है। Combinations की हाथ से चुनी list ऐसे gaps छोड़ती है जो किसी को दिखते नहीं; combinatorial set का एक घोषित, जाँचने लायक लक्ष्य होता है, जैसे "delivery, customer type और coupon का हर allowed triple", इसलिए जो छूटता है वह फ़ैसला होता है, संयोग नहीं।
Tester के लिए यह test count को एक तर्क बना देता है: set क्या guarantee करता है, क्या नहीं, और ज़्यादा strength कितनी महँगी पड़ेगी।
Strength: कितने parameters का मिलना ज़रूरी है
Strength 1 वही each choice coverage है जो आपने equivalence partitioning में देखी: हर value कम से कम एक बार आती है। Strength 2 (pairwise) किन्हीं दो parameters की values के हर pair को किसी test में साथ रखती है, strength 3 हर triple को, और जब t parameters की संख्या के बराबर हो जाए तो आप फिर सभी combinations पर पहुँच जाते हैं। ISTQB glossary इसे n-wise testing कहती है; NIST और कई tools t-way कहते हैं। किसी strength तक पहुँचने वाला test set covering array कहलाता है।
कोई भी t-way set सबसे बड़ी t value-counts के गुणनफल से छोटा नहीं हो सकता: चार-चार values वाले दो parameters 16 pairs बनाते हैं और एक test उनमें से सिर्फ़ एक रखता है, इसलिए pairwise को कम से कम 16 tests चाहिए। Checkout के लिए ठीक 16, 64 और 256 tests वाले sets मौजूद हैं। हर ऊँचा step minimum को लगभग values की संख्या से गुणा कर देता है, इसलिए strength risk के हिसाब से चुनी जाती है, अपने-आप अधिकतम नहीं की जाती।
ये minimum sizes हैं; इस model के लिए ठीक इन्हीं sizes वाले sets मौजूद हैं। Constraints और असमान value counts ये numbers बदल देते हैं, और generator minimum से ज़्यादा rows दे सकता है।
पाठ संस्करण
Checkout: 5 parameters x 4 values each
Strength Every test set must contain Minimum
1-way (each choice) every value at least once 4
2-way (pairwise) every pair of values, any 2 parameters 16
3-way every triple of values, any 3 parameters 64
4-way every combination of any 4 parameters 256
5-way (all combinations) 4 x 4 x 4 x 4 x 4 1,024Parameters के बीच constraints
कुछ combinations असंभव होते हैं: shop Apple Pay सिर्फ़ web पर और iOS app में देता है। अगर generator यह नहीं जानता तो कुछ rows execute नहीं हो सकतीं, और बाद में उन्हें delete करने से वे दूसरे pairs भी हट जाते हैं जो वे rows ले जा रही थीं। इसलिए generate करने से पहले constraints declare करें, ताकि हर allowed combination cover हो और कोई forbidden combination न आए। नीचे का notation सामान्य है; हर tool का अपना notation होता है। Pairwise Testing Generator forbidden combination को Payment = Apple Pay AND Device = Android app के रूप में लेता है, और नीचे दिया implication जैसा लिखा है वैसा ही स्वीकार करता है।
- Forbidden combination:
NOT (Payment = Apple Pay AND Device = Android app)। - Implication:
IF Customer = guest THEN Payment <> bank transfer(bank transfer के लिए account चाहिए, इसलिए page guests को यह option दिखाता ही नहीं)। - Conditional parameter: card scheme सिर्फ़ card payment में मायने रखता है; उसे "not applicable" value दें या classification tree में refinement के रूप में model करें।
- Constraint नहीं: ऐसा combination जिस तक user पहुँच सकता है पर system को उसे reject करना चाहिए। उसे expected result वाले test के रूप में रखें; invalid values के लिए, pairwise testing की तरह, अलग negative tests बनाएँ।
Classification tree method
Classification tree method, जिसे Grochtmann और Grimm ने 1993 में describe किया, model को चित्र के रूप में बनाती है ताकि team उसे review कर सके। Test object root है; उसके नीचे classifications हैं, यानी वे पहलू जो result बदल सकते हैं; और हर classification classes में बँटती है, जो equivalence partitions हैं। किसी class को एक और classification से refine किया जा सकता है, जैसे "card" के नीचे card scheme।
Tree के नीचे combination table होती है: हर row एक test case है जो लागू होने वाली हर classification की एक class mark करती है। Coverage rule rows की संख्या तय करता है: हर class एक बार, हर pair, ऊँची strength, या सभी combinations।
Checkout (test object)
|-- Payment
| |-- card --> Card scheme: Visa | Mastercard | mada
| |-- Apple Pay
| |-- bank transfer
| `-- cash on delivery
|-- Delivery: standard | express | same-day | store pickup
|-- Customer: guest | new account | returning | business
|-- Device: desktop web | mobile web | Android app | iOS app
`-- Coupon: none | percentage | fixed amount | free shipping
Combination table (one row = one test case, one class per classification)
TC Payment Scheme Delivery Customer Device Coupon
1 card mada express business iOS app fixed amount
2 Apple Pay - store pickup guest desktop web free shipping
3 bank transfer - same-day returning Android app nonePairs से आगे कब जाएँ
Pairwise एक समझदार default है: NIST का research बताता है कि जिन software का उसने अध्ययन किया, उनमें ज़्यादातर failures किसी एक parameter से या दो parameters के interaction से हुए, और तीन या ज़्यादा parameters वाले failures क्रमशः कम होते गए। यह एक प्रवृत्ति है, guarantee नहीं।
Pairs से आगे जाने का मतलब शायद ही कभी पूरे model के लिए t बढ़ाना होता है। Mixed strength इस्तेमाल करें: सभी parameters के लिए 2-way रखें और t सिर्फ़ interact करने वाले group के लिए बढ़ाएँ, जैसा नीचे का worked example delivery fee के लिए करता है। अगर logic साफ़ rules के रूप में लिखा हो, तो decision table उसे बेहतर टेस्ट कर सकती है। Parameters के किसी group के लिए 3-way या उससे ऊपर तब सोचें जब:
- एक rule तीन या ज़्यादा parameters को जोड़ता है: fees, prices, eligibility, permissions।
- Failure महँगा पड़ेगा: पैसा, स्वास्थ्य, कानूनी दायित्व या data का नुकसान।
- पहले किसी defect में तीन parameters साथ शामिल थे।
- Tests automated और सस्ते हैं, इसलिए 64 rows की लागत 16 से बहुत ज़्यादा नहीं।
Worked example: checkout के test set की planning
Checkout में पाँच parameters हैं, हर एक की चार classes, जो equivalence partitioning से ली गई हैं; card scheme छोड़ दिया गया है क्योंकि, जैसा एक developer ने पुष्टि की, payment provider सभी schemes को एक जैसा handle करता है। एक requirement कहती है कि delivery fee delivery option, customer type और coupon, तीनों पर साथ में निर्भर है। Product owner ने तीन constraints की पुष्टि की: Android app में Apple Pay उपलब्ध नहीं है, store pickup के साथ cash on delivery उपलब्ध नहीं है, और guests को bank transfer नहीं दिखाया जाता।
Plan user interface से pairwise चलाता है, जहाँ tests धीमे हैं, और fee के सभी 64 triples data-driven API tests के रूप में, जहाँ वे सस्ते हैं। Constraints न होते तो 16 tests हर pair cover कर देते; constraints के साथ 16 तक पहुँचना संभव नहीं। हर payment method और हर device को चारों coupons से मिलना है, इसलिए 16 rows में हर एक को ठीक चार बार आना होगा। तब Apple Pay की चार rows सिर्फ़ तीन devices इस्तेमाल कर सकती हैं और Android app की चार rows सिर्फ़ तीन payment methods, इसलिए Payment–Device के दो pairs दोहराए जाते हैं और 15 allowed pairs के लिए कम से कम 17 rows चाहिए। Pairwise Testing Generator इस model के लिए 22 rows देता है। Free-shipping coupon के साथ store pickup संभव है, इसलिए वह constraint नहीं बल्कि उन्हीं triples में से एक है, उस expected result के साथ जो product owner ने तय किया। कुल मिलाकर यह 1,024 combinations का लगभग 8% है, और हर हिस्से की एक घोषित guarantee है।
Parameters (4 values each)
Payment card | Apple Pay | bank transfer | cash on delivery
Delivery standard | express | same-day | store pickup
Customer guest | new account | returning | business
Device desktop web | mobile web | Android app | iOS app
Coupon none | percentage | fixed amount | free shipping
Constraints
NOT (Payment = Apple Pay AND Device = Android app)
NOT (Payment = cash on delivery AND Delivery = store pickup)
IF Customer = guest THEN Payment <> bank transfer
Plan
UI 2-way, all 5 parameters at least 17 tests (generator: 22)
API 3-way, Delivery x Customer x Coupon 64 tests, every fee triple
Not planned: all combinations 1,024 (832 allowed)आम गलतियाँ
- हर parameter की strength "सुरक्षा के लिए" बढ़ा देना, जिससे tests की संख्या कई गुना हो जाती है; strength सिर्फ़ वहीं बढ़ाएँ जहाँ parameters interact करते हैं।
- किसी combination को constraint घोषित करना क्योंकि system को उसे reject करना चाहिए, जिससे उसकी error handling कभी टेस्ट नहीं होती।
- Rule से ज़्यादा चौड़ा constraint लिखना, जैसे Apple Pay को सिर्फ़ Android app की बजाय हर जगह exclude कर देना, जिससे valid combinations बिना किसी के ध्यान दिए testing से बाहर हो जाते हैं।
- ऐसा classification tree बनाना जिसकी classes overlap करें या gaps छोड़ें, जिससे एक input दो classes में आए या किसी में नहीं।
- Strength एक बार चुनकर फिर कभी न देखना, जबकि नए rules या incidents दिखा रहे हों कि ज़्यादा parameters interact करते हैं।
- t-way coverage को सबूत मान लेना: यह दिखाती है कि कौन-से combinations चले, यह नहीं कि हर result जाँचा गया या model पूरा है।
QA का नज़रिया
Model test analysis और design के दौरान product owner के साथ बनाएँ, जो पुष्टि करता है कि कौन-से combinations असंभव हैं और किन पर error दिखनी चाहिए, और एक developer के साथ, जो जानता है कि code असल में किन parameters को जोड़ता है। तीन inputs से fee calculate करने वाला function 3-way का मज़बूत संकेत है।
Parameters के हर group की strength और उसका कारण model के साथ लिखें, ताकि reviewers देख सकें कि 22 या 86 tests क्यों हैं। Incidents के बाद इसे दोबारा देखें: अगर production failure के लिए तीन values एक साथ ज़रूरी थीं, तो उन parameters को 3-way group में ले जाएँ और कारण दर्ज करें।
अभ्यास
Hotel booking form के लिए combinatorial test set plan करें
एक hotel booking form में नीचे दिए छह parameters और तीन rules हैं। Form को model करें, rules को constraints और tests में बाँटें, और हर हिस्से के लिए strength plan करें। फिर pairwise हिस्से को Pairwise Testing Generator से जाँचें।
Hotel booking form (web और app)
Room standard | deluxe | suite
Guests 1 | 2 | 3
Board room only | breakfast | half board
Payment pay now by card | pay at hotel
Member loyalty member | not a member
Channel web | app
Rule A: Standard room में ज़्यादा से ज़्यादा 2 guests रह सकते हैं। Standard room
चुनने पर guest selector 3 का option नहीं दिखाता।
Rule B: Pay at hotel सिर्फ़ loyalty members के लिए है। अगर non-member इसे चुनता है,
तो page "Hotel में pay करने के लिए sign in करें" दिखाता है।
Rule C: Price room, guests और board को मिलाकर calculate होती है।- हर parameter के लिए एक classification वाला classification tree बनाएँ।
- तय करें कि Rule A और Rule B constraints हैं या tests।
- सभी combinations, allowed combinations, और 1-way व 2-way sets का minimum size calculate करें।
- Rule C से तय करें कि 3-way कहाँ चाहिए और उसके लिए कम से कम कितने tests चाहिए।
- Rule A declare करके pairwise set generate करें, फिर उसका size, pair coverage और हर row Rule A के सामने जाँचें।
मॉडल उत्तर दिखाएँ
Tree: root booking form है, उसके नीचे हर parameter के लिए एक classification, और दी गई values उसकी classes हैं।
Rule A constraint है, क्योंकि form यह combination असंभव बनाता है: NOT (Room = standard AND Guests = 3)। Rule B constraint नहीं है: non-member pay at hotel चुन सकता है, इसलिए यह test रहता है, जिसका expected result sign-in message है।
सभी combinations: 3 × 3 × 3 × 2 × 2 × 2 = 216; Rule A 1 × 1 × 3 × 2 × 2 × 2 = 24 हटाता है, 192 बचते हैं। 1-way set को कम से कम 3 tests चाहिए और 2-way set को कम से कम 9, क्योंकि अकेले Room × Board के 9 pairs हैं। Rule A के साथ 9 तक पहुँचना संभव नहीं। नौ rows में Room–Board और Guests–Board का हर pair ठीक एक बार आना होगा, इसलिए हर room type और guests की हर संख्या ठीक तीन बार आएगी। Standard room की तीन rows में सिर्फ़ 1 या 2 guests हो सकते हैं और 3 guests वाली तीन rows में सिर्फ़ deluxe या suite, इसलिए Room–Guests के दो pairs दोहराए जाते हैं और 8 allowed Room–Guests pairs के लिए 10 rows चाहिए। 10 rows वाला set मौजूद है, इसलिए constraint के साथ minimum 10 है।
Rule C, Room, Guests और Board को जोड़ता है: 27 triples में से वे 3 घटाएँ जिन्हें Rule A रोकता है, तो 24 बचते हैं, यानी कम से कम 24 tests, और बाकी parameters ऐसे फैले हों कि उनके pairs cover रहें। यह mixed strength है: इन तीन parameters के लिए 3-way, बाकी के लिए 2-way।
हर parameter अलग line में डालें, जैसे Room: standard, deluxe, suite, और Rule A को Room = standard AND Guests = 3 के रूप में declare करें, जिसे tool forbidden combination मानता है। Tool को 92 value pairs (93 में से forbidden pair घटाकर) दिखाने चाहिए, सभी covered। Generator minimum 10 की जगह 11 rows दे सकता है; हर allowed pair cover करने वाला कोई भी set सही है। अगर कोई row standard room को 3 guests के साथ जोड़ती है, तो constraint लागू नहीं हुआ: row delete करने की बजाय constraint declare करके set दोबारा generate करें।
अक्सर पूछे जाने वाले सवाल
क्या combinatorial testing और pairwise testing एक ही हैं?
Pairwise testing strength 2 वाला combinatorial testing है। Combinatorial testing सामान्य technique है: कोई भी strength, parameters के अलग-अलग groups के लिए mixed strength, और ऐसे constraints जो असंभव combinations हटाते हैं।
मुझे कौन-सी strength चुननी चाहिए?
सभी parameters के लिए 2-way से शुरू करें। जिन parameters को एक rule जोड़ता है या जहाँ failure महँगा है, उनके लिए 3-way करें, और 4-way या उससे ज़्यादा सिर्फ़ automated tests वाले छोटे, critical हिस्सों के लिए सोचें। Strength risk का फ़ैसला है, इसलिए लिखें कि आपने इसे क्यों चुना।
क्या test set बनाने के लिए tool ज़रूरी है?
कुछ से ज़्यादा parameters हों तो हाँ: covering arrays हाथ से बनाना धीमा है और उसमें गलती आसानी से होती है। Model फिर भी आपका काम है। Output जाँचें: rows की संख्या, कि कोई forbidden combination नहीं आया, और जहाँ tool बताता हो, कि चुनी गई strength पर coverage पूरी है।
क्या classification tree equivalence partitioning की जगह ले लेता है?
नहीं, यह उसी पर बनता है। Tree की classes equivalence partitions हैं, और boundary values भी classes बन सकती हैं। Tree कई पहलुओं के partitions को एक चित्र में व्यवस्थित करता है, और combination table चुनती है कि उनमें से कौन-से साथ टेस्ट होंगे।
संदर्भ
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
- ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsसॉफ़्टवेयर टेस्टिंग का अंतरराष्ट्रीय मानक: अवधारणाएँ, प्रक्रियाएँ, दस्तावेज़ीकरण और तकनीकें।
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
Mutqan tools से अभ्यास करें
पैरामीटर और उनकी वैल्यू से न्यूनतम pairwise (all-pairs) टेस्ट सेट जनरेट करें।
हर इनपुट के लिए वैध और अमान्य equivalence class निकालें और हर क्लास से एक प्रतिनिधि टेस्ट वैल्यू चुनें।
conditions और actions से decision table बनाएँ, सभी rule संयोजन जनरेट करें और असंभव संयोजनों को समेट दें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।