"It Worked in the Demo": Why Software Needs Proper Testing

In a demo, the developer types a sensible name, a valid phone number and a normal amount. In your shop, someone types a discount larger than the bill, presses Save twice, and loses internet halfway through a payment. Software that has only seen the demo breaks on the first busy day.

What QA checks

• Wrong input: empty fields, negative numbers, Bangla text, very long names
• Money: totals, discounts, VAT and dues adding up to the last taka
• Permissions: a cashier cannot open what only the owner should see
• Real devices: a mid-range Android phone on mobile data
• Two people doing the same thing at the same moment

Manual and automated testing

A person testing by hand is good at noticing that something feels wrong. Automated tests are good at repetition: the same hundred checks run after every change, in minutes. Their real value appears later, when fixing one thing would otherwise quietly break another.

A bug found late costs more

A wrong calculation caught before launch is an hour of work. The same bug found after three months means correcting three months of invoices and explaining it to customers. Testing looks like a cost on the quote; skipping it moves the cost to a worse day.

What to ask your vendor

• Who tests the software: the same developer, or someone else?
• Is there a test site where we can try changes before they go live?
• Are the payment and billing flows covered by automated tests?
• What happens when we report a bug after launch?