Why happy-path testing lies
The typical UAT script says: "Create a sales order with two lines, confirm, deliver, invoice. Expected: invoice created." It passes. Everyone signs. Then on the first month-end a sales order that was partially delivered needs a price change, the customer is over their credit limit, and the invoice has to carry VDS because the buyer is a withholding entity. Nobody tested that, because nobody wrote it down.
Happy paths pass because the consultant configured the system for them. The value of UAT comes from deliberately going where configuration is weakest: exceptions, late changes, foreign currency, partial quantities, missing approvals and tax edge cases.
The anatomy of a useful test case
Every case in your script should have five parts. If one is missing, the case is weaker than it looks.
| Part | Weak version | Useful version |
|---|---|---|
| Persona | "User" | Shila, the AP accountant |
| Moment | (none) | On the last working day of the month |
| Constraint | (none) | The vendor is a service provider with no TIN |
| Steps | "Create bill" | Create bill from PO, post, register payment |
| Measurable result | "Bill is created" | TDS at the no-TIN rate is deducted; payment = bill − TDS; certificate data is available |
The last row matters most. "Screen shows X" is a smoke test. A UAT result must be something a finance or operations person can verify with numbers: stock value equals received quantity × PO price × exchange rate on the receipt date, or the tax report's output VAT equals the GL balance of the output VAT account.
Force exactly one variable off the happy path per case. If you change three things at once and it fails, you won't know which one broke it.
Where to find the scenarios
You don't need to invent them. They're already in your business:
- The as-is process maps from discovery. Every pain point you recorded ("GRN posted days late", "6.3 numbering errors") becomes at least one test case.
- Last year's problems. Ask accounts for the five worst month-ends, and ask the warehouse for the five worst stock discrepancies. Turn each into a case.
- Compliance rules. Every Mushak form you need, every TDS category, the VDS rules, wage-board OT, and landed cost for imports. These are where Bangladeshi implementations most often fail.
- The approval matrix. Test every approval threshold just below and just above the limit.
Bangladesh cases every project should include
These cases catch the configuration gaps I see most often. They're all in the UAT template ready to adapt:
- TDS on a vendor without a TIN, which is charged at a higher rate. It's often configured for one category only.
- VDS on a sale to a withholding entity: the invoice is paid net, and the 6.6 certificate must be tracked.
- Landed cost on an import: CD, RD and SD increase unit cost, while VAT and AT at import go to VAT receivable, not to cost. Get this wrong and every margin report is wrong. Check it against the import duty calculator.
- Export invoice at 0% via fiscal position, showing on the zero-rated line of the tax report.
- Mushak 6.3 print: both BINs, correct serial numbering, VAT per line, and SD where applicable.
- Quarterly VAT data: the tax report for three months reconciles with the GL, with the monthly advance deposits recorded.
- Payroll for a worker with OT and one absent day: OT at basic ÷ 208 × 2, absence deducted, attendance bonus not paid. Check it against the wage calculator.
- Access rights: a store keeper must not see product cost or vendor prices.
How many cases?
For a mid-sized manufacturer on Accounting, Inventory, Purchase, Sales and Manufacturing, 80–150 cases is normal, with about a third marked Must. Fewer than 40 usually means the edge cases are missing. More than 300 usually means the same happy path is being tested repeatedly with different product codes.
Prioritise with MoSCoW, like the requirements. Must cases are the ones where a failure would stop go-live. Should cases can go live with a documented workaround.
End-to-end cases
Module-by-module testing misses the handovers. Include at least one case per core process that runs across modules with the real users of each step: a sales order that triggers manufacturing, which triggers purchasing of a short component, which is received with landed cost, consumed, produced, delivered, invoiced with Mushak 6.3, and paid net of VDS. When that single chain reconciles in stock, cost and tax, you've learned more than from 30 isolated cases.
Every module passes UAT on its own, then the first end-to-end test shows the finished-goods cost ignores the landed cost of imported material, because the landed cost was validated after the manufacturing order consumed the stock. Sequencing problems like this only show up end-to-end.
Exercise (20 minutes). Take your three biggest pain points from discovery. Write each as a test case using the five parts: persona, moment, constraint, steps, measurable result. Then write one end-to-end case for your main order-to-cash chain.
Key takeaways
- Every case needs a persona, a moment, a constraint, steps and a measurable result.
- Force one variable off the happy path per case.
- Mine scenarios from pain points, past problems, compliance rules and approval limits.
- Include end-to-end chains; handovers between modules are where most defects hide.
Go deeper: The UAT script I wish I'd written 200 users ago.