बिज़नेस रूल्स
Business rule एक ऐसा कथन है जो तय करता है या सीमित करता है कि कोई संगठन कैसे काम करता है: कोई policy, regulation, contract की शर्त या calculation। "Customer delivery के 14 दिन के अंदर item return कर सकता है, जब तक वह gift card न हो" एक business rule है। यह software के बिना भी लागू रहता है, और returns संभालने वाले हर channel को इसे एक ही तरह लागू करना होगा।
पिछले lesson में business rules को functional requirements के विषयों में गिना गया था। ज़्यादा सटीक कहें तो rule ख़ुद कोई software requirement नहीं है, न functional न non-functional, बल्कि requirements का स्रोत है: functional requirements system का वह behaviour हैं जो rule को लागू करता है। सिर्फ़ returns rule से कई requirements बनती हैं: 14वें दिन के बाद return button छिपाना, API में देर से आई requests reject करना, customer को कारण बताना। Tester के लिए हर rule conditions और expected outcomes का एक तैयार set है।
यह क्यों ज़रूरी है
Rules से पैसा, कानूनी दायित्व और customers का भरोसा जुड़ा होता है। गलत implementation गलत price लगाता है, गलत customer को discount देता है या ऐसा return स्वीकार करता है जिसे policy मना करती है, और screen फिर भी काम करती है: गलत outcome सिर्फ़ conditions के किसी ख़ास combination पर दिखता है।
Rules बिखरे हुए भी होते हैं और बदलते भी हैं। जब किसी को पता नहीं होता कि rule कहाँ लिखा है या उसका owner कौन है, तो release के बाद team बहस करती है कि system को क्या करना चाहिए था। हर rule ढूँढना, उसे testable रूप में लिखना और उसके combinations cover करना, यह बहस और defects दोनों रोकता है।
Business rules के प्रकार
एक प्रचलित classification, Karl Wiegers और Joy Beatty की किताब Software Requirements से, rules को facts, constraints, action enablers, inferences और computations में बाँटता है। Facts business के बारे में सच्चे कथन हैं, और action enablers conditions पूरी होने पर कोई action शुरू करते हैं; बाकी तीन प्रकार ज़्यादातर test design तय करते हैं।
- Constraint: तय करता है कि क्या नहीं हो सकता। "Ship हो चुका order cancel नहीं किया जा सकता।" मना किया गया action करके देखें और जाँचें कि वह साफ़ message के साथ reject होता है, सिर्फ़ user interface में नहीं, API में भी।
- Computation: एक formula जो value देता है। "Late fee: हर पूरे महीने के लिए बकाया राशि का 2%, अधिकतम 10%।" Expected values rule से ख़ुद calculate करें, rounding और cap समेत।
- Inference: conditions से एक नया fact निकालता है। "जिस customer के पिछले 12 महीनों में 5 या ज़्यादा orders deliver हुए हैं, वह Gold member है।" जाँचें कि status मिलता है और conditions पूरी न रहने पर हट भी जाता है; दूसरे rules, जैसे नीचे का free shipping rule, इस पर निर्भर हैं।
Business rules कहाँ छिपे होते हैं
User story feature का नाम बताती है, लेकिन उसके पीछे का rule अक्सर कहीं और लिखा होता है, या कहीं नहीं। Rule मिलने पर उसे एक बार identifier, source, owner और effective date के साथ दर्ज करें, जैसे नीचे की catalogue entry में, और test cases को उससे link करें: तब policy बदलने पर पता चलता है कि कौन-से tests update करने हैं। आम छिपने की जगहें:
- Documents और spreadsheets: terms and conditions, return policies, partner contracts, finance और pricing की sheets, जो अक्सर किसी computation का असली घर होती हैं।
- Domain experts और support staff के दिमाग़: "हम batteries कभी air से ship नहीं करते"।
- मौजूदा system: hard-coded conditions, configuration tables, database constraints और triggers (वे checks और logic जो database data बदलने पर ख़ुद लागू करता है), scheduled jobs, जो legacy system बदलते समय आसानी से खो जाते हैं।
- Requirements में vague शब्द: "eligible", "valid", "regular customer", "unless", "by default"। हर शब्द ऐसे rule की ओर इशारा करता है जिसे किसी ने लिखा नहीं।
ID: BR-03
Type: Constraint
Statement: Customer delivery के 14 दिन के अंदर item return कर सकता है,
जब तक item gift card न हो।
Source: Returns policy v4, section 2
Owner: Head of Customer Operations
Effective: 2026-01-01
Applies to: Order page, Returns API, Support console
Tests: TC-201, TC-202, TC-203, TC-204Decision table से rule टेस्ट करना
कई conditions वाले rules में ही combinations छूटते हैं। ISTQB Foundation syllabus decision tables को ऐसे complex logic को दर्ज करने का असरदार तरीका बताता है और उदाहरण के तौर पर business rules का नाम लेता है। Conditions और actions rows बनाते हैं; हर column एक decision rule है, यानी condition values का एक combination और उसके actions। Entries T (true) या F (false) होती हैं; X उस action को दिखाता है जो होना चाहिए, और खाली cell उस action को जो नहीं होना चाहिए।
पहले rule को ऐसे दोबारा लिखें कि उसके हिस्से दिखें: BR-03 दो conditions बन जाता है जो AND से जुड़ी हैं, दोनों सच होने पर एक action, और बाकी हालात में दूसरा action।
BR-03 को IF, THEN और ELSE से लिखने पर उसकी दो conditions decision table की condition rows और दो outcomes उसकी action rows बन जाते हैं।Returns rule BR-03, दोबारा लिखा गया
भाग 1:BR-03 IF
- 2–3Conditions: condition rows
- 4–5Outcomes: action rows
- 1Rule identifierRule को उसके source document और उसे cover करने वाले हर test case से जोड़ता है।
- 2Condition 1Policy के "14 दिन के अंदर" से। पूछें कि दिन कैसे गिने जाते हैं और delivery के किस पल से।
- 3Condition 2: exceptionPolicy का "जब तक … न हो"
AND NOTबन जाता है। - 4दोनों conditions सच हों तो actionReturn स्वीकार होता है।
- 5वरना वाला actionRequirement में आसानी से छूट जाता है: customer कौन-सा message देखता है, और क्या उसमें कारण लिखा है?
- Conditions और actions लिखें।
- Condition values का हर combination एक column में लिखें: दो true/false conditions से 4 columns बनते हैं, तीन से 8। एक तय pattern अपनाएँ जिसमें पहली row सबसे धीरे बदले (
T T T T F F F F, फिरT T F F T T F F, फिरT F T F T F T F), ताकि कोई combination न छूटे और न दोहराया जाए। - हर column के expected actions rule के text से भरें, चलते हुए system से नहीं।
- जो column आप भर न सकें, वह gap या contradiction है: किसी के code लिखने से पहले rule owner से पूछें।
- हर feasible column (ऐसा column जिसका combination सच में हो सकता है) के लिए कम से कम एक test case लिखें; ISTQB की भाषा में यही columns coverage items हैं।
पाठ संस्करण
BR-03 IF days_since_delivery <= 14
AND NOT item.is_gift_card
THEN return.accepted
ELSE return.refusedWorked example: free shipping का rule
Product owner लिखता है: "Gold members को हमेशा free shipping मिलती है। बाकी customers को 200.00 SAR या उससे ज़्यादा के orders पर free shipping मिलती है और उससे कम पर standard fee लगती है। Oversized items कभी free ship नहीं होते।" इससे तीन conditions बनती हैं (Gold member, कम से कम 200.00 SAR का total, order में oversized item) और दो actions (free shipping, standard fee)।
| Decision table column | Gold member | 200.00 SAR या ज़्यादा का total | Order में oversized item | Expected shipping |
|---|---|---|---|---|
| Column 1 | T | T | T | Standard feeproduct owner का फ़ैसला |
| Column 2 | T | T | F | Free shipping |
| Column 3 | T | F | T | Standard feeproduct owner का फ़ैसला |
| Column 4 | T | F | F | Free shipping |
| Column 5 | F | T | T | Standard feeproduct owner का फ़ैसला |
| Column 6 | F | T | F | Free shipping |
| Column 7 | F | F | T | Standard fee |
| Column 8 | F | F | F | Standard fee |
- Free shipping
- यहाँ मूल wording का एक वाक्य shipping free करता था और दूसरा कहता था "कभी free नहीं"; product owner ने फ़ैसला किया
यहाँ हर row, text version वाली decision table का एक column है। T: condition सच है; F: सच नहीं है।
8 columns एक contradiction दिखाते हैं। Columns 1 और 3 में Gold member oversized item मँगाता है, और "हमेशा free" और "कभी free नहीं" दोनों सच नहीं हो सकते। Column 5 में एक non-Gold customer (जो Gold member नहीं है) कम से कम 200.00 SAR का order देता है जिसमें oversized item है, और वहाँ दूसरे और तीसरे वाक्य के बीच यही टकराव है। Tester table product owner को दिखाता है, जो तय करता है कि oversized items पर हमेशा standard fee लगेगी, और जवाब requirement में लिखा जाता है। फिर हर column के लिए एक test case पूरा rule cover करता है:
- Columns 2 और 4: बिना oversized item वाला Gold member, 250.00 और 80.00 SAR पर: free shipping।
- Columns 6 और 8: बिना oversized item वाला non-Gold customer, ठीक 200.00 SAR पर: free; 199.99 SAR पर: standard fee। Limit पर ही टेस्ट करने से
>=की जगह लिखा गया>पकड़ में आता है। - Columns 1, 3, 5 और 7: वही चार orders, लेकिन oversized item जोड़कर (Gold member 250.00 और 80.00 SAR पर, non-Gold customer 200.00 और 199.99 SAR पर): हर बार standard fee। Columns 1, 3 और 5 product owner के नए फ़ैसले को टेस्ट करते हैं।
पाठ संस्करण
1 2 3 4 5 6 7 8
Conditions
Gold member T T T T F F F F
Order total >= 200.00 SAR T T F F T T F F
Oversized item in order T F T F T F T F
Actions
Free shipping X X X
Standard fee X X X X Xआम गलतियाँ
- सिर्फ़ story के example वाला combination टेस्ट करना, conditions के बाकी combinations नहीं।
- Constraint सिर्फ़ user interface में जाँचना: button का छिपा होना कुछ साबित नहीं करता अगर API अब भी request स्वीकार करती है।
- Expected results system से या developer की spreadsheet से लेना, बजाय उन्हें rule से calculate करने के।
- "eligible" या "regular customer" जैसे vague शब्द, उन्हें define करने वाले rule के बारे में पूछे बिना, स्वीकार कर लेना।
- "वरना" वाला outcome भूल जाना: conditions पूरी न होने पर customer क्या देखता है, कितना चुकाता है या उसे क्या बताया जाता है।
- Rule का source, owner और effective date दर्ज न करना, जिससे किसी को पता नहीं चलता कि policy बदलने पर कौन-से test cases पुराने हो गए।
QA का नज़रिया
Business rules सबसे पहले refinement और requirements review में सामने आते हैं। Story में हर condition वाला शब्द पूछने का संकेत है: rule ठीक-ठीक क्या है, कहाँ लिखा है, और उसे बदलने का फ़ैसला कौन करता है? Meeting में decision table बनाना जल्दी ही वे combinations सामने ले आता है जिनके बारे में किसी ने सोचा नहीं था। जवाब requirement या rule catalogue में दर्ज करें, किसी chat thread में नहीं।
Computations के लिए rule owner से worked examples माँगें, जैसे finance द्वारा calculate किए गए invoices: वे आपके formula पढ़ने से बेहतर test oracle हैं। किसी rule पर bug report में rule, conditions का combination, expected outcome और उसका source, और actual outcome लिखा होता है।
अभ्यास
Promotion rule को वर्गीकृत करें और decision table बनाएँ
नीचे एक food-delivery app का marketing brief है जिसमें पाँच statements हैं। हर statement को constraint, computation या inference में वर्गीकृत करें, फिर discount के लिए decision table बनाएँ और test cases निकालें; food subtotal 100.00 SAR और delivery fee 15.00 SAR लें।
Promotion brief: "Welcome और student offer"
1. Customer तब तक "new" है जब तक उसका पहला order deliver नहीं हो जाता।
2. New customers को food subtotal पर 20% छूट मिलती है।
3. Verified student account वाले customers को food subtotal पर 10% छूट मिलती है।
4. Discounts जोड़े नहीं जा सकते: दोनों लागू हों तो सिर्फ़ बड़ा discount मिलता है।
5. Delivery fee पर कभी discount नहीं मिलता।- Statements 1 से 5 को वर्गीकृत करें।
- Discount के फ़ैसले की conditions और actions चुनें।
- हर column का discount और customer द्वारा चुकाई जाने वाली राशि भरें।
- हर column के लिए एक test case लिखें और rule owner के लिए अपने सवालों की सूची बनाएँ।
मॉडल उत्तर दिखाएँ
प्रकार: statement 1 inference है (order history से "new" status निकालता है); 2 और 3 computations हैं (हर एक एक राशि, यानी discount, देता है); 4 और 5 constraints हैं (ये सीमित करते हैं कि discounts कैसे लागू हो सकते हैं)।
Conditions: new customer और verified student। Actions: 20% छूट, 10% छूट, कोई छूट नहीं। Column 1 (T, T): 20% छूट, क्योंकि statement 4 सिर्फ़ बड़ा discount देता है; column 2 (T, F): 20% छूट; column 3 (F, T): 10% छूट; column 4 (F, F): कोई छूट नहीं।
Test cases, हर एक में food subtotal 100.00 SAR और delivery fee 15.00 SAR: verified student account वाला new customer 95.00 SAR (80.00 + 15.00) चुकाता है, column 1; बिना ऐसे account वाला new customer भी 95.00 SAR चुकाता है, column 2; verified student जो अब new नहीं है 105.00 SAR चुकाता है, column 3; कोई और customer 115.00 SAR चुकाता है, column 4। Delivery fee हर case में 15.00 SAR ही रहती है।
सवाल: पहला order cancel हो जाए तो क्या customer अब भी new है? क्या पहली delivery से पहले दिए गए दोनों orders पर 20% छूट मिलती है? Discount VAT से पहले लगता है या बाद में, और rounding कैसे होती है?
अक्सर पूछे जाने वाले सवाल
क्या business rule और requirement एक ही चीज़ हैं?
नहीं। Business rule संगठन में मौजूद होता है, चाहे कोई software उसे implement करे या नहीं; requirements बताती हैं कि किसी ख़ास system को क्या करना है। एक rule से आम तौर पर कई functional requirements बनती हैं, और एक requirement कई rules implement कर सकती है। कुछ teams rules सीधे acceptance criteria के रूप में लिखती हैं, जो तब तक ठीक है जब तक हर rule एक ही जगह दर्ज हो और उन stories से linked हो जो उसे इस्तेमाल करती हैं।
Decision table अपने columns को "rules" क्यों कहती है?
Decision table की terminology में हर column एक decision rule है: condition values का एक combination और उसके बाद होने वाले actions। तीन true/false conditions वाला एक business rule ऐसे 8 तक columns बनाता है, इसलिए दोनों शब्दों के अर्थ अलग हैं। भ्रम से बचना हो तो "column" कहें।
अगर rule में table के लिए बहुत ज़्यादा conditions हों तो?
हर true/false condition के साथ columns की संख्या दोगुनी हो जाती है: 10 conditions से 1,024 columns बनते हैं। Rule को छोटे rules में बाँटें, जो combinations हो ही नहीं सकते उन्हें हटाएँ, और उन columns को मिलाएँ जहाँ कोई condition outcome नहीं बदलती। Decision table testing का lesson इन तरीकों को विस्तार से सिखाता है; पहला ज़रूरी कदम है चुनने से पहले सभी combinations देखना।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
Mutqan tools से अभ्यास करें
conditions और actions से decision table बनाएँ, सभी rule संयोजन जनरेट करें और असंभव संयोजनों को समेट दें।
क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।
फ़ॉर्म फ़ील्ड के लिए validation टेस्ट केस बनाएँ: required, फ़ॉर्मेट, लंबाई, रेंज, pattern और cross-field नियम।
प्रतिशत, प्रतिशत परिवर्तन, वृद्धि/कमी और X, Y का कितना प्रतिशत है — सब गिनें।
किसी तारीख़ में दिन, सप्ताह, महीने, वर्ष, घंटे और मिनट जोड़ें या घटाएँ।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।