पेयरवाइज़ टेस्टिंग

Pairwise testing, जिसे all-pairs testing भी कहते हैं, एक black-box test design technique है उन features के लिए जो कई parameters पर निर्भर हैं और हर parameter की कुछ ही values हैं। हर combination टेस्ट करने की बजाय आप tests ऐसे चुनते हैं कि किन्हीं भी दो parameters की values की हर जोड़ी कम से कम एक test में साथ आए। 3 browsers, 3 operating systems और 3 languages में supported web shop के 27 combinations हैं, फिर भी अच्छी तरह चुने गए 9 tests में हर browser–OS, browser–language और OS–language pair आ जाता है।

यह equivalence partitioning पर बनती है: partitioning हर parameter को उसकी values देती है, हर partition से एक representative, और pairwise testing तय करती है कि tests की संख्या गुणा किए बिना उन्हें कैसे मिलाएँ।

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

कई failures तभी दिखते हैं जब दो settings मिलती हैं: layout जो सिर्फ़ Firefox में Arabic के साथ टूटता है, price जो सिर्फ़ US dollars में yearly billing पर गलत आता है। हर value को एक बार टेस्ट करना इन interactions को छोड़ देता है, और हर combination टेस्ट करना शायद ही संभव होता है, क्योंकि हर parameter के साथ गिनती गुणा होती जाती है।

Pairwise testing एक systematic बीच का रास्ता है। "जो configurations हम आम तौर पर आज़माते हैं" की जगह team को एक छोटा set मिलता है जिसकी coverage बताई और जाँची जा सकती है, जैसे "9 tests में सभी 27 value pairs"।

सारे combinations टेस्ट करना क्यों बेकाबू हो जाता है

Parameter कोई भी चीज़ है जो स्वतंत्र रूप से बदलती है: browser, operating system, interface language, user role, payment method, feature flag। Combinations की संख्या values की संख्याओं का गुणनफल है, इसलिए हर नया parameter total को गुणा कर देता है।

दूसरे छोर पर है each choice coverage, जो आपने equivalence partitioning वाले lesson में देखी: हर value कम से कम एक test में आए, इसलिए जब हर parameter की तीन values हों तो तीन tests काफ़ी हैं। यह सस्ती है, लेकिन किन्हीं दो खास values को कभी जानबूझकर साथ नहीं लाती।

  • 3 browsers × 3 operating systems × 3 languages = 27 combinations।
  • Screen size (phone, tablet, desktop) जोड़ें: 27 × 3 = 81।
  • दो user roles (guest, signed-in) जोड़ें: 81 × 2 = 162, यानी हर manual run के 10 मिनट के हिसाब से 27 घंटे।
  • तीन-तीन values वाले दस parameters: 3^10 = 59,049 combinations।

All-pairs coverage का मतलब

Value pair का मतलब है एक parameter की एक value, दूसरे parameter की एक value के साथ, जैसे Browser = Chrome के साथ Language = Arabic; ISTQB glossary इसे pair of parameter-value pairs कहती है। Value pairs इस technique के coverage items हैं: pairwise coverage उन value pairs का प्रतिशत है जिन्हें कम से कम एक test चलाता है, और pairwise set 100% तक पहुँचता है।

Set इसलिए छोटा रहता है क्योंकि एक test एक साथ कई pairs कवर करता है: Chrome · Windows · Arabic से Chrome–Windows, Chrome–Arabic और Windows–Arabic कवर होते हैं। Test में जितने ज़्यादा parameters, उतने ज़्यादा pairs, इसलिए parameters जुड़ने पर pairwise set धीरे-धीरे बढ़ता है।

कोई भी set सबसे बड़े parameter की values की संख्या गुणा दूसरे सबसे बड़े parameter की values की संख्या से छोटा नहीं हो सकता: 4 browsers और 3 operating systems के लिए कम से कम 12 tests चाहिए। ज़्यादातर tools greedy algorithms इस्तेमाल करते हैं जो छोटा set ढूँढते हैं, हमेशा सबसे छोटा नहीं; ज़रूरी है 100% pair coverage।

Parameters:        Browser (3), OS (3), Language (3)

All combinations:  3 × 3 × 3                  = 27 tests

Value pairs:       Browser–OS         3 × 3  =  9
                   Browser–Language   3 × 3  =  9
                   OS–Language        3 × 3  =  9
                   total                     = 27 pairs

Pairs in one test: 3 (one per pair of parameters)
Fewest tests:      3 × 3 (two largest)       =  9 tests
                   27 pairs / 3 per test     =  9, so each pair appears once

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

Worked example: browser × OS × language का pairwise set

एक checkout page को Chrome, Firefox और Edge में, Windows, macOS और Linux पर, English, Arabic (right to left) और Hindi में चलना है। Safari छोड़ा गया है क्योंकि वह सिर्फ़ Apple platforms पर चलता है, इसलिए Safari–Windows असंभव है; ऐसे pairs को बाहर रखने वाले rules, जिन्हें constraints कहते हैं, combinatorial testing वाले lesson का विषय हैं।

Set हाथ से बनाएँ। एक grid बनाएँ जिसकी rows browsers हों और columns operating systems: उसके 9 ख़ाने 9 browser–OS pairs हैं, हर एक का एक test। फिर हर ख़ाने में एक language ऐसे लिखें कि हर language हर row में एक बार और हर column में एक बार आए। तब हर row में सारे browser–language pairs होते हैं, और हर column में सारे OS–language pairs।

नौ tests browser, operating system और language के सभी 27 value pairs कवर करते हैं: हर ख़ाना एक test है, और हर language हर row और हर column में एक बार आती है।
ब्राउज़रऑपरेटिंग सिस्टम
WindowsmacOSLinux
Chromeअंग्रेज़ी#1अरबी#2हिंदी#3
Firefoxअरबी#4हिंदी#5अंग्रेज़ी#6
Edgeहिंदी#7अंग्रेज़ी#8अरबी#9
  • अंग्रेज़ी
  • अरबी
  • हिंदी
Grid कैसे पढ़ें
ख़ाना एक test: उसकी row का browser, उसके column का operating system और उसमें लिखी language। 9 ख़ाने ही 9 browser–OS pairs हैं।
पंक्ति (row) तीनों languages एक-एक बार आती हैं, इसलिए हर browser–language pair कवर होता है।
स्तंभ (column) तीनों languages एक-एक बार आती हैं, इसलिए हर OS–language pair कवर होता है।

सारे combinations टेस्ट करने में 27 tests लगते। यह layout, जिसे Latin square कहते हैं, 9 tests के कई valid sets में से एक है।

  • हर row एक configuration है, test case नहीं: वही checkout scenario, अपने steps और expected results के साथ, सभी नौ configurations में चलाएँ।
  • Pairwise Testing Generator इस input के लिए 10 tests लौटा सकता है; 100% pair coverage वाला कोई भी set सही है।
  • Windows पर Chrome में Arabic इस set में नहीं है, हालाँकि उसका हर pair मौजूद है। अगर analytics दिखाते हैं कि ज़्यादातर customers यही इस्तेमाल करते हैं, तो इसे दसवें test के रूप में जोड़ें: pairwise testing हर pair को बराबर अहम मानती है, risk ऐसा नहीं मानता।
पाठ संस्करण
#  Browser  OS       Language
1  Chrome   Windows  English
2  Chrome   macOS    Arabic
3  Chrome   Linux    Hindi
4  Firefox  Windows  Arabic
5  Firefox  macOS    Hindi
6  Firefox  Linux    English
7  Edge     Windows  Hindi
8  Edge     macOS    English
9  Edge     Linux    Arabic

9 tests instead of 27 combinations; 27 of 27 value pairs covered

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

Pairwise testing कहाँ रुक जाती है

Pairwise testing मानकर चलती है कि interaction failure को दिखने के लिए ज़्यादा से ज़्यादा दो खास values चाहिए। यह हर pair की गारंटी देती है, हर triple की नहीं: जिस failure के लिए Chrome, Windows और Arabic एक साथ चाहिए, वह तभी मिलता है जब संयोग से वह triple set में हो।

  • तीन या ज़्यादा values के interactions छूट सकते हैं। High-risk features के लिए 3-wise testing इस्तेमाल करें, जो हर pair की जगह values का हर triple कवर करती है; combinatorial testing वाला lesson इसका तरीका दिखाता है।
  • यह values खुद नहीं चुनती: value list से छूटा partition या boundary कभी टेस्ट नहीं होता, इसलिए पहले equivalence partitioning और boundary value analysis से values चुनें।
  • इसे असंभव या अहम combinations का पता नहीं होता: असंभव pairs के लिए constraints चाहिए, और अहम configurations जानबूझकर जोड़नी होती हैं।
  • Invalid values combined set में नहीं होनी चाहिए: दो invalid values वाला test आम तौर पर पहली error पर रुककर दूसरी को छिपा देता है, जिसे masking कहते हैं। हर invalid value को अलग से टेस्ट करें।
  • यह हर समस्या पर फ़िट नहीं होती: जब business rule खास combinations से नतीजा तय करता है तो decision table, और जब events का क्रम मायने रखता है तो state transition testing इस्तेमाल करें।

आम गलतियाँ

  • सिर्फ़ सारे pairs कवर होने पर "सारे combinations कवर" report करना; कहें: "9 tests में 27 में से 27 value pairs"।
  • Values की जगह raw ranges डालना, जैसे 1 से 100 तक की हर age, जबकि partitions के representatives और ज़रूरी boundaries चाहिए।
  • Pairwise model में invalid values मिला देना, जिससे एक reject हुआ input बाकी inputs को mask कर देता है।
  • असंभव निकली rows को दोबारा generate किए बिना हटा देना, जिससे उन rows के बाकी pairs चुपचाप गायब हो जाते हैं।
  • नया browser या language जोड़ना, लेकिन set दोबारा generate न करना और coverage फिर से न जाँचना।
  • ज़्यादातर customers की असली configuration छोड़ देना, सिर्फ़ इसलिए कि generator ने संयोग से उसे नहीं चुना।

QA का नज़रिया

जब भी test basis ऐसे options गिनाए जो आपस में मिलते हैं, pairwise testing इस्तेमाल करें: supported browsers और devices, languages, roles, plans, payment methods, feature flags। Test analysis और test design के दौरान model लिखें (parameters, values, असंभव combinations) और उसे developers और product owner के साथ review करें: कौन-सी values सच में supported हैं, कौन-से pairs हो ही नहीं सकते, और analytics, support tickets और server logs की User-Agent strings के हिसाब से कौन-सी configurations सबसे अहम हैं।

Model को test cases के साथ testware के रूप में रखें: parameters, constraints, इस्तेमाल किया गया tool, generated set और हासिल coverage। तब कुछ भी जुड़ने पर आप दोबारा generate कर सकते हैं और report में ठीक-ठीक बता सकते हैं कि क्या कवर हुआ और क्या नहीं। जब कोई configuration fail हो, तो एक बार में एक value बदलकर वह value या pair ढूँढें जिससे failure होता है, और bug report में उसी का नाम लिखें।

अभ्यास

Subscription checkout के लिए pairwise set बनाएँ

आपका काम

एक subscription sign-up page नीचे दिए चार parameters को मिलाता है, और हर combination allowed है। Combinations और value pairs गिनें, हाथ से pairwise set बनाएँ, और उसकी तुलना Pairwise Testing Generator से करें।

फिर एक combination बताएँ जो आपके set में नहीं है, और बताएँ कि आप उसे extra test के रूप में कब जोड़ेंगे।

सामग्री
Plan:     Basic, Pro, Business
Payment:  card, wallet, bank transfer
Billing:  monthly, yearly
Currency: SAR, USD
चरण
  1. सारे combinations गिनें।
  2. Parameters की हर जोड़ी के value pairs गिनें, फिर total।
  3. दो सबसे बड़े parameters से tests की न्यूनतम संख्या निकालें।
  4. नौ ख़ानों वाले Plan × Payment grid से शुरू करें, फिर billing और currency ऐसे भरें कि हर pair आ जाए।
  5. यही parameters Pairwise Testing Generator में चलाएँ और आकार व coverage की तुलना करें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Combinations: 3 × 3 × 2 × 2 = 36।

Value pairs: Plan–Payment 9, Plan–Billing 6, Plan–Currency 6, Payment–Billing 6, Payment–Currency 6, Billing–Currency 4; total 37। न्यूनतम 3 × 3 = 9 tests है, हर Plan–Payment pair के लिए एक।

एक valid set: Basic · card · monthly · SAR, Basic · wallet · yearly · SAR, Basic · bank transfer · monthly · USD, Pro · card · yearly · USD, Pro · wallet · monthly · SAR, Pro · bank transfer · monthly · SAR, Business · card · monthly · SAR, Business · wallet · monthly · USD, Business · bank transfer · yearly · SAR। हर plan और हर payment method दोनों billing periods और दोनों currencies के साथ आता है, और billing–currency के चारों pairs मौजूद हैं।

Generator 10 tests लौटा सकता है; सभी 37 pairs वाला कोई भी set सही है। इस set में नहीं है: Business plan, bank transfer से, USD में; अगर यह रास्ता high-risk है, जैसे विदेश के business customers के बड़े invoices, तो इसे जोड़ें।

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

क्या pairwise testing और orthogonal arrays एक ही हैं?

पूरी तरह नहीं। Orthogonal array pairwise set बनाने का एक तरीका है जिसमें हर pair बराबर बार आता है; इस lesson का 9-test उदाहरण ऐसा ही है। Pairwise testing सिर्फ़ इतना माँगती है कि हर pair कम से कम एक बार आए, जिससे generators अलग-अलग संख्या की values वाले parameters और असंभव combinations संभाल पाते हैं।

Pairwise set में कितने tests चाहिए?

कम से कम सबसे बड़े parameter की values की संख्या गुणा दूसरे सबसे बड़े parameter की values की संख्या। उसके बाद आकार धीरे बढ़ता है: lesson के उदाहरण में screen size जोड़ने पर combinations 27 से 81 हो जाते हैं, फिर भी 9 tests सभी 54 value pairs कवर कर सकते हैं, और तीन-तीन values वाले दस parameters (59,049 combinations, 405 value pairs) 30 से कम tests में आ जाते हैं।

क्या pairwise testing सिर्फ़ configurations के लिए है या form inputs के लिए भी?

Form inputs के लिए भी, जब कई inputs एक-दूसरे से स्वतंत्र हों और हर एक की कुछ representative values हों, जैसे search page के filters। जब कोई business rule शर्तों के खास combinations से नतीजा तय करता है, तब decision table बेहतर technique है।

संदर्भ

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

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

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

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

User-Agent स्ट्रिंग से ब्राउज़र, वर्शन, इंजन, OS, डिवाइस टाइप और बॉट की पहचान करें।

वेब

और गहराई से

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

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