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

बाउंड्री वैल्यू एनालिसिस

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

Boundary value analysis (BVA) एक black-box test design technique है जो equivalence partitions के किनारों पर मौजूद values को टेस्ट करती है। Boundary value किसी ordered partition की सबसे छोटी या सबसे बड़ी value होती है: अगर कोई field 18 से 65 तक की age स्वीकार करता है, तो valid partition की boundaries 18 और 65 हैं, और उसके बगल वाले invalid partitions की boundaries 17 और 66 हैं।

BVA सीधे equivalence partitioning पर बनती है। Partitioning बताती है कि system को inputs के किन groups के साथ एक जैसा व्यवहार करना चाहिए; BVA बताती है कि उन groups के अंदर कहाँ देखना है, क्योंकि किनारों पर ही logic बदलता है और वहीं गलतियाँ इकट्ठा होती हैं।

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

Developers "18 से 65" जैसे rules को comparisons से लिखते हैं: age >= 18 && age <= 65। >= की जगह > लिख देना, या requirement गलत पढ़कर गलत limit लगा देना, ऐसा defect बनाता है जो सिर्फ़ एक exact value पर दिखता है। Range के बीच की आम values, जैसे 30, comparison सही हो या गलत, दोनों हालात में pass हो जाती हैं।

हर boundary को सिर्फ़ दो या तीन test values चाहिए, इसलिए BVA कुछ ही tests से defects की पूरी category पकड़ लेती है। यही वजह है कि यह tester की सबसे सस्ती और सबसे असरदार techniques में से एक है, और यह सिर्फ़ numbers तक सीमित नहीं: lengths, dates, quantities, file sizes, prices और counts, सबके किनारे होते हैं।

Boundaries वहीं होती हैं जहाँ values का क्रम होता है

BVA उन partitions पर लागू होती है जिनकी values का क्रम होता है: numbers, dates, times, string lengths, sizes, list में positions। "Payment method: card, cash या wallet" के partitions हैं लेकिन boundaries नहीं, क्योंकि "cash" न "card" से छोटा है न बड़ा। Unordered values के लिए सिर्फ़ equivalence partitioning इस्तेमाल करें।

शुरुआत partitions लिखकर करें, invalid partitions समेत। 18 से 65 तक के whole numbers स्वीकार करने वाले age field के तीन partitions हैं: 18 से कम (invalid), 18 से 65 (valid) और 65 से ज़्यादा (invalid)। हर दो बगल वाले partitions एक boundary पर मिलते हैं।

  • Numbers: minimum और maximum; step size (whole numbers, या पैसों के लिए 0.01) तय करता है कि पड़ोसी value कौन-सी है।
  • Lengths: 2 से 50 characters वाले नाम की boundaries 1|2 और 50|51 characters पर हैं।
  • Dates और times: "31 मार्च तक valid" की boundary 31 मार्च 23:59:59 और 1 अप्रैल 00:00:00 के बीच है — किसी तय time zone में।
  • Counts और sizes: "अधिकतम 5 attachments, हर एक अधिकतम 10 MB" से boundaries 5|6 files पर और 10 MB व उससे एक byte ऊपर बनती हैं।

2-value और 3-value boundary value analysis

ISTQB Foundation syllabus दो variants परिभाषित करता है। 2-value BVA में हर boundary के लिए आप boundary value खुद और बगल वाले partition में उसकी सबसे नज़दीकी पड़ोसी value टेस्ट करते हैं। 3-value BVA में आप boundary value और उसके दोनों पड़ोसी, हर तरफ़ एक, टेस्ट करते हैं।

Age field (whole numbers, valid 18 से 65) के लिए 2-value BVA से 17, 18, 65 और 66 मिलते हैं। 3-value BVA से 17, 18, 19, 64, 65 और 66 मिलते हैं। Extra values 19 और 64 ऐसे defects पकड़ती हैं जहाँ developer ने operator सही लिखा पर limit गलत, जैसे age <= 65 की जगह age < 65 — तब 65 reject होगा, जिसे 2-value भी पकड़ लेता है — या ऐसा code जो boundary को special case मानकर उसके बगल वाली value बिगाड़ देता है।

Age field, valid 18–65: 2-value BVA 17, 18, 65 और 66 टेस्ट करता है; 3-value BVA valid partition के ठीक अंदर 19 और 64 जोड़ता है।

age: integer, valid 18..65

अक्ष 17 से 66 तक
  • ≤ 17अमान्य: बहुत कम
  • 18–65वैध partition
  • ≥ 66अमान्य: बहुत ज़्यादा
  1. 117 निचला पड़ोसीरिजेक्टफ़ेल
  2. 218 निचली boundaryस्वीकारपास
  3. 319 अंदर का पड़ोसीसिर्फ़ 3-value में · स्वीकार
  4. 464 अंदर का पड़ोसीसिर्फ़ 3-value में · स्वीकार
  5. 565 ऊपरी boundaryस्वीकारपास
  6. 666 ऊपरी पड़ोसीरिजेक्टफ़ेल
पाठ संस्करण
Field: age, whole numbers, valid 18..65

Partitions:   [ ... 17 ] [ 18 ......... 65 ] [ 66 ... ]
                invalid         valid           invalid

2-value BVA:  17  18                    65  66
3-value BVA:  17  18  19            64  65  66

Expected:     17 rejected, 18 accepted, 19 accepted,
              64 accepted, 65 accepted, 66 rejected

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

Worked example: delivery fee का नियम

Requirement: "100.00 SAR से कम के orders पर 15.00 SAR delivery fee लगती है। 100.00 से 299.99 SAR तक के orders पर 7.50 SAR। 300.00 SAR या उससे ज़्यादा के orders की delivery free है।" Prices में दो decimal places हैं, इसलिए पड़ोसी values के बीच step 0.01 है।

Partitions हैं: 100.00 से कम, 100.00 से 299.99, और 300.00 व उससे ऊपर। Valid partitions के बीच दो boundaries हैं, और एक तीसरी नीचे: order total शून्य या negative नहीं हो सकता, इसलिए 0.00 और 0.01 भी मायने रखते हैं।

  • 0.00 → reject (खाली order नहीं); 0.01 → fee 15.00।
  • 99.99 → fee 15.00; 100.00 → fee 7.50।
  • 299.99 → fee 7.50; 300.00 → free delivery।
  • हर partition के लिए एक typical value भी जोड़ें (जैसे 50.00, 180.00, 750.00) ताकि दिखे कि पूरा partition एक जैसा व्यवहार करता है — यह equivalence partitioning का हिस्सा है।

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

छिपी हुई boundaries जिनका requirement में ज़िक्र नहीं

कई boundaries requirement में लिखी नहीं होतीं लेकिन system में मौजूद होती हैं: database column की maximum length, data type में आने वाला सबसे बड़ा number, upload की size limit, फ़रवरी का आख़िरी दिन, session expire होने का पल। ये implicit boundaries production के कुछ सबसे महँगे defects बनाती हैं, क्योंकि किसी ने इनके लिए test plan नहीं किया होता।

Technical limits के लिए developer से पूछें या API contract या schema पढ़ें, फिर वही technique लागू करें: limit, और उसके ठीक बाहर वाली value।

  • 100 characters वाले column में stored text: 100 और 101 characters टेस्ट करें, और characters उसी तरह गिनें जैसे system गिनता है — Arabic या Hindi text letters में नहीं, bytes में नापा जा सकता है।
  • 32-bit signed integer: 2147483647 और 2147483648।
  • Dates: leap और non-leap years में 28/29 फ़रवरी, और time zones के बीच तारीख़ का बदलना।

आज़माएँ: स्ट्रिंग लेंथ काउंटर आज़माएँ: तारीख़ टेस्ट डेटा जनरेटर

आम गलतियाँ

  • हर boundary का सिर्फ़ valid पक्ष (18 और 65) टेस्ट करना और reject होने वाली values (17 और 66) कभी टेस्ट न करना।
  • यह तय न करना कि limit inclusive है या नहीं: "18 और 65 के बीच", "65 तक" और "65 से कम" के अलग-अलग मतलब हैं। पूछें और जवाब test case में लिखें।
  • गलत step लेना: prices में 100.00 की पड़ोसी value 99.99 है, 99 नहीं।
  • Payment methods या country codes जैसी unordered values पर BVA लगाना, जहाँ इसका कोई अर्थ नहीं।
  • Field lengths, type limits और date edges जैसी implicit boundaries भूल जाना।
  • Boundaries टेस्ट करना पर बीच के partitions छोड़ देना — BVA equivalence partitioning का पूरक है, उसका विकल्प नहीं।

QA का नज़रिया

Practice में BVA requirements review के दौरान ही शुरू हो जाती है: requirement में हर number, length या date inclusivity, units और step size के बारे में एक सवाल है। Coding से पहले "क्या 65 की age eligible है?" पूछ लेना defect को बाद में ढूँढने की बजाय पहले ही रोक देता है।

Test cases लिखते समय हर boundary value को उसका अपना case या data-driven table में अपनी row दें, expected result साफ़ लिखकर। अगर कोई fail हो, तो bug report में exact value, expected result और जिस comparison पर शक है वह लिखें — तब developer off-by-one error मिनटों में ठीक कर सकता है।

अभ्यास

Password rule की boundary values खोजें

आपका काम

Sign-up form कहता है: "Password 12 से 64 characters लंबा होना चाहिए।" Length characters में गिनी जाती है। Partitions पहचानें, फिर हर value के expected result के साथ 2-value और 3-value boundary values लिखें।

फिर requirement में जो अब भी अस्पष्ट हो उसे product owner के लिए सवाल के रूप में लिखें।

चरण
  1. Password length के partitions लिखें, invalid partitions समेत।
  2. बगल वाले partitions के बीच की दो boundaries चिह्नित करें।
  3. 2-value set लिखें, फिर उसे 3-value set तक बढ़ाएँ।
  4. हर value का expected result (accept या reject) लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Partitions: 0 से 11 characters (invalid), 12 से 64 (valid), 65 और ज़्यादा (invalid)। Boundaries: 11|12 और 64|65।

2-value BVA: 11 (reject), 12 (accept), 64 (accept), 65 (reject)। 3-value BVA इनमें 13 और 63 जोड़ता है (दोनों accept)।

यह भी टेस्ट करने लायक है: खाली password (0 characters), जो पहले partition का सबसे निचला किनारा है और अक्सर उसका अपना error message होता है।

खुले सवाल: emoji या diacritics वाले Arabic letters कैसे गिने जाते हैं? Length spaces trim करने से पहले जाँची जाती है या बाद में? क्या database या hashing library में कोई अलग maximum है?

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

क्या boundary value analysis और equivalence partitioning एक ही हैं?

नहीं। Equivalence partitioning inputs को ऐसे groups में बाँटती है जिनका व्यवहार एक जैसा होना चाहिए और हर group से एक value टेस्ट करती है। फिर boundary value analysis ordered groups के किनारे टेस्ट करती है, जहाँ व्यवहार बदलता है। आम तौर पर दोनों साथ इस्तेमाल होती हैं।

2-value BVA इस्तेमाल करूँ या 3-value?

Default रूप से 2-value BVA इस्तेमाल करें; यह कम tests में ज़्यादातर off-by-one defects पकड़ती है। Prices, limits और eligibility जैसे high-risk rules के लिए, या जब code boundaries को special तरीके से handle करता हो, 3-value BVA इस्तेमाल करें।

क्या BVA dates और text पर काम करती है?

हाँ, जब भी values ordered हों: dates और times, text length, file size, item counts और positions, सबकी boundaries होती हैं। यह colours या payment methods जैसी unordered values पर लागू नहीं होती।

संदर्भ

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

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

तारीख़ टेस्ट डेटा जनरेटर

तारीख़ों के डेटासेट जनरेट करें: किसी रेंज में रैंडम तारीख़ें, leap day, महीने के अंत, DST किनारे और कई फ़ॉर्मेट।

टेस्ट डेटा

और गहराई से

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

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