Learning Objectives
By the end of this lesson you will be able to:
- Identify which validation belongs at the UI layer and which at the business layer
- Select inputs that specifically target business rule enforcement on the server
- Explain why frontend enforcement of business rules is insufficient
What's a Business Rule?
A business rule is a constraint derived from the organization's requirements — not from the data type:
- "Age must be between 18 and 70 to apply for a driver's license" (business rule)
- "Age must be a positive integer" (data type constraint)
Both need validation. But business rules are more critical to test at the backend, because they encode the organization's legal, financial, or operational requirements. Getting them wrong isn't just a UX problem — it's a compliance or liability problem.
The Three Categories of Server-Side Validation
1. Format Validation
- Is this a valid email address format?
- Is this a valid date (not 2024-02-30)?
- Is the phone number the right number of digits?
2. Range and Type Validation
- Is the age in the valid range?
- Is the quantity a positive integer?
- Is the price within acceptable limits?
3. Business Rule Validation
- Does this user have sufficient balance for this transaction?
- Is this coupon code valid and not yet expired?
- Has this user already reached their daily request limit?
Category 3 cannot be checked by the frontend alone — it requires database access, external service calls, or state that only the server has.
Testing Business Rules
For each business rule in the specification:
- Test the boundary case: inputs that are exactly at the rule's threshold
- Test just inside the rule: inputs that should pass
- Test just outside the rule: inputs that should be rejected
- Test the server directly: bypass the frontend to confirm the rule is enforced server-side
Example — rule: "Maximum 3 failed login attempts before account lockout":
- Submit 2 failed attempts → account still active
- Submit 3rd failed attempt → account still active (threshold = after 3rd fail)
- Submit 4th attempt → account should be locked
Pro Tip: Business rules are often the most poorly tested area of a system because they require testers to understand the domain, not just the UI. Reading the specification carefully — looking for "must," "shall," "only if," "unless" — will reveal the business rules that need testing.
Key Takeaways
- Business rules must be enforced on the server, not just the frontend
- Three categories: format, range/type, business rule — all require server-side enforcement
- Boundary test each business rule just like you'd BVA a numeric range
- Test business rules by bypassing the frontend to verify server-side enforcement