Business Rules
A business rule is a statement that defines or limits how an organisation works: a policy, a regulation, a contract term or a calculation. "A customer may return an item within 14 days of delivery, unless it is a gift card" is a business rule. It holds even without software, and every channel that handles returns must apply it the same way.
The previous lesson listed business rules among the topics of functional requirements. More precisely, a rule is not itself a software requirement, functional or non-functional, but a source of them: the functional requirements are the system behaviour that applies it. The returns rule alone leads to several: hide the return button after day 14, reject late requests in the API, tell the customer why. For a tester, each rule is a ready-made set of conditions and expected outcomes.
Why it matters
Rules carry money, legal obligations and customer trust. A wrong implementation charges the wrong price, gives a discount to the wrong customer or accepts a return the policy forbids, and the screen still works: only a particular combination of conditions shows the wrong outcome.
Rules are also scattered, and they change. When nobody knows where a rule is written or who owns it, the team argues after release about what the system should have done. Finding each rule, writing it in a testable form and covering its combinations prevents both the argument and the defects.
Types of business rules
A widely used classification, from Karl Wiegers and Joy Beatty’s book Software Requirements, sorts rules into facts, constraints, action enablers, inferences and computations. Facts are true statements about the business, and action enablers trigger an action when conditions hold; the other three shape most test design.
- Constraint: restricts what may happen. "An order cannot be cancelled once it has shipped." Try the forbidden action and check that it is refused with a clear message, in the API as well as in the user interface.
- Computation: a formula that produces a value. "Late fee: 2% of the overdue amount per full month, at most 10%." Calculate the expected values yourself from the rule, including rounding and the cap.
- Inference: derives a new fact from conditions. "A customer with 5 or more delivered orders in the last 12 months is a Gold member." Check that the status is granted, and removed when the conditions stop being true; other rules, such as the free-shipping rule below, depend on it.
Try it: Validation Test Generator Try it: Percentage Calculator
Where business rules hide
A user story names a feature, but the rule behind it is often written somewhere else, or nowhere. When you find a rule, record it once with an identifier, source, owner and effective date, as in the catalogue entry below, and link test cases to it: a policy change then tells you which tests to update. Typical hiding places:
- Documents and spreadsheets: terms and conditions, return policies, partner contracts, finance and pricing sheets, often the real home of a computation.
- The heads of domain experts and support staff: "we never ship batteries by air".
- The existing system: hard-coded conditions, configuration tables, database constraints and triggers (checks and logic the database applies by itself when data changes), scheduled jobs, all easy to lose when a legacy system is replaced.
- Vague words in requirements: "eligible", "valid", "regular customer", "unless", "by default". Each one points to a rule nobody has written down.
ID: BR-03
Type: Constraint
Statement: A customer may return an item within 14 days of delivery,
unless the item is a 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-204Testing a rule with a decision table
Rules with several conditions are where combinations get missed. The ISTQB Foundation syllabus describes decision tables as an effective way to record such complex logic and names business rules as an example. Conditions and actions form the rows; each column is a decision rule, one combination of condition values with its actions. Entries are T (true) or F (false); X marks an action that should happen, and a blank marks one that should not.
First rewrite the rule so that its parts are visible: BR-03 becomes two conditions joined by AND, an action when both hold and another action otherwise.
BR-03 rewritten with IF, THEN and ELSE: its two conditions become the condition rows of a decision table, and its two outcomes become the action rows.Returns rule BR-03, rewritten
Part 1:BR-03 IF
- 2–3Conditions: the condition rows
- 4–5Outcomes: the action rows
- 1Rule identifierLinks the rule to its source document and to every test case that covers it.
- 2Condition 1From the policy’s “within 14 days”. Ask how days are counted and from which moment of delivery.
- 3Condition 2: the exceptionThe policy’s “unless” becomes
AND NOT. - 4Action when both conditions are trueThe return is accepted.
- 5Action otherwiseEasy to leave out of a requirement: which message does the customer see, and does it say why?
- List the conditions and the actions.
- Write every combination of condition values as a column: two true/false conditions give 4 columns, three give 8. Use a fixed pattern, the first row changing slowest (
T T T T F F F F, thenT T F F T T F F, thenT F T F T F T F), so that no combination is missed or repeated. - Fill in each column’s expected actions from the rule, not from the running system.
- A column you cannot fill is a gap or a contradiction: ask the rule owner before anyone codes it.
- Write at least one test case per feasible column, one whose combination can actually occur; in ISTQB terms, these columns are the coverage items.
Text version
BR-03 IF days_since_delivery <= 14
AND NOT item.is_gift_card
THEN return.accepted
ELSE return.refusedWorked example: a free-shipping rule
A product owner writes: "Gold members always get free shipping. Other customers get free shipping on orders of 200.00 SAR or more and pay the standard fee below that. Oversized items are never shipped free." That gives three conditions (Gold member, a total of at least 200.00 SAR, an oversized item in the order) and two actions (free shipping, standard fee).
| Decision table column | Gold member | Total of 200.00 SAR or more | Oversized item in the order | Expected shipping |
|---|---|---|---|---|
| Column 1 | T | T | T | Standard feedecided by the product owner |
| Column 2 | T | T | F | Free shipping |
| Column 3 | T | F | T | Standard feedecided by the product owner |
| Column 4 | T | F | F | Free shipping |
| Column 5 | F | T | T | Standard feedecided by the product owner |
| Column 6 | F | T | F | Free shipping |
| Column 7 | F | F | T | Standard fee |
| Column 8 | F | F | F | Standard fee |
- Free shipping
- Here one sentence of the original wording made shipping free and another said “never free”; the product owner decided
Each row here is one column of the decision table in the text version. T: the condition is true; F: it is false.
The 8 columns expose a contradiction. In columns 1 and 3 a Gold member orders an oversized item, and "always free" and "never free" cannot both hold. Column 5, a customer who is not a Gold member spending 200.00 SAR or more on an order with an oversized item, has the same conflict between the second and third sentences. The tester shows the table to the product owner, who decides that oversized items always pay the standard fee, and the answer goes into the requirement. One test case per column then covers the rule:
- Columns 2 and 4: a Gold member without oversized items, at 250.00 and at 80.00 SAR: free shipping.
- Columns 6 and 8: a customer who is not a Gold member, without oversized items, at exactly 200.00 SAR: free; at 199.99 SAR: standard fee. Testing right at the limit catches
>written instead of>=. - Columns 1, 3, 5 and 7: the same four orders with an oversized item added (a Gold member at 250.00 and at 80.00 SAR, a customer who is not a Gold member at 200.00 and at 199.99 SAR): standard fee every time. Columns 1, 3 and 5 check the product owner’s new decision.
Text version
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 XCommon mistakes
- Testing only the combination in the story’s example, not the other combinations of conditions.
- Checking a constraint only in the user interface: a hidden button proves nothing if the API still accepts the request.
- Taking expected results from the system or the developer’s spreadsheet instead of calculating them from the rule.
- Accepting vague words such as "eligible" or "regular customer" without asking for the rule that defines them.
- Forgetting the "otherwise" outcome: what the customer sees, pays or is told when the conditions are not met.
- Not recording a rule’s source, owner and effective date, so nobody knows which test cases a policy change has made outdated.
The QA perspective
Business rules surface first in refinement and requirements review. Every condition word in a story is a cue to ask: what exactly is the rule, where is it written, and who decides when it changes? Sketching a decision table in the meeting quickly brings out combinations nobody had considered. Record the answers in the requirement or the rule catalogue, not in a chat thread.
For computations, ask the rule owner for worked examples, such as invoices calculated by finance: they are a better test oracle than your own reading of a formula. A bug report on a rule names the rule, the combination of conditions, the expected outcome with its source and the actual outcome.
Practice exercise
Classify a promotion rule and build its decision table
The marketing brief below, for a food-delivery app, contains five statements. Classify each as a constraint, a computation or an inference, then build a decision table for the discount and derive test cases, using a food subtotal of 100.00 SAR and a delivery fee of 15.00 SAR.
Promotion brief: "Welcome and student offer"
1. A customer is "new" until their first order has been delivered.
2. New customers get 20% off the food subtotal.
3. Customers with a verified student account get 10% off the food subtotal.
4. Discounts cannot be combined: when both apply, only the larger one is given.
5. The delivery fee is never discounted.- Classify statements 1 to 5.
- Choose the conditions and actions of the discount decision.
- Fill in each column’s discount and the amount the customer pays.
- Write one test case per column and list your questions for the rule owner.
Show the model answer
Types: statement 1 is an inference (it derives "new" from the order history); 2 and 3 are computations (each produces an amount, the discount); 4 and 5 are constraints (they restrict how discounts may be applied).
Conditions: new customer and verified student. Actions: 20% off, 10% off, no discount. Column 1 (T, T): 20% off, because statement 4 gives only the larger discount; column 2 (T, F): 20% off; column 3 (F, T): 10% off; column 4 (F, F): no discount.
Test cases, each with a food subtotal of 100.00 SAR and a delivery fee of 15.00 SAR: a new customer with a verified student account pays 95.00 SAR (80.00 + 15.00), column 1; a new customer without one also pays 95.00 SAR, column 2; a verified student who is no longer new pays 105.00 SAR, column 3; any other customer pays 115.00 SAR, column 4. The delivery fee stays 15.00 SAR in every case.
Questions: if the first order is cancelled, is the customer still new? Do two orders placed before the first delivery both get 20% off? Is the discount applied before or after VAT, and how is it rounded?
Frequently asked questions
Is a business rule the same as a requirement?
No. A business rule exists in the organisation whether or not any software implements it; requirements describe what a particular system must do. One rule usually leads to several functional requirements, and one requirement may implement several rules. Some teams write rules directly as acceptance criteria, which works as long as each rule is recorded once and linked to the stories that use it.
Why does a decision table call its columns "rules"?
In decision table terminology each column is a decision rule: one combination of condition values and the actions that follow. One business rule with three true/false conditions produces up to 8 such columns, so the two words mean different things. Say "column" when you need to avoid confusion.
What if a rule has too many conditions for a table?
The number of columns doubles with every true/false condition: 10 conditions give 1,024 columns. Split the rule into smaller rules, remove combinations that cannot occur, and merge columns where a condition does not change the outcome. The lesson on decision table testing covers these techniques; the important first step is to see every combination before you choose.
References
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
Practise with Mutqan tools
Build decision tables from conditions and actions, generate all rule combinations and collapse impossible ones.
Convert a list of numbered requirements into traceable test cases with a requirement-to-test matrix.
Generate validation test cases for form fields: required, format, length, range, pattern and cross-field rules.
Calculate percentages, percentage change, increase/decrease and what percent X is of Y.
Add or subtract days, weeks, months, years, hours and minutes from a date.
Go deeper
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.