How much of a software project budget should go to testing?

There is no single right percentage, but the practical rule is that testing should be part of the estimate for each feature rather than a separate line item that gets cut under budget pressure. Systems handling money, personal data, or government integrations need higher coverage than a simple brochure site.

Can I cut costs by removing testing from the scope of work?

You can cut the first invoice, not the cost. A defect found after launch needs diagnosis, a fix, redeployment, and repair of corrupted data, all paid later at a higher price. A quote that dropped testing is not cheaper; it simply deferred the bill.

What is the difference between user acceptance testing and the other tests?

The other tests are the technical team's responsibility and verify that the system works as designed. User acceptance testing is yours and your team's responsibility, and verifies that the system actually serves your business against your real scenarios. No sign-off should happen before it is complete.

Is it acceptable to use real customer data in the test environment?

It is a common and risky practice. The Personal Data Protection Law governs the processing of personal data whatever environment it sits in, and test environments usually have broader access and weaker protection. The alternative is synthetically generated data, or real data with sensitive fields masked.

Software Testing and QA: Why One System Succeeds and Another Fails on the Same Budget

Short answer: software testing and quality assurance are not a final stage before handover — they decide how much your system will cost you after launch. Two systems with identical budgets diverge at one point: was it built with test coverage that catches defects before your customer does, or is your customer the test suite? In the first, you pay for quality once during the build. In the second, you pay monthly in outages, emergency fixes, and eroded trust.

QA is not "someone clicking around before delivery"

The common picture among business owners is that quality means one person opening screens and pressing buttons in the last week of the project. That is a very small — and the least effective — part of it. Real quality assurance is a system running from day one: requirements written precisely enough to be testable, code covered by automated tests that run on every change, a staging environment that mirrors production, and a deployment path that will not let a change reach production before it clears those gates.

The practical difference is simple: in the first setup a defect surfaces minutes after it is written; in the second your customer finds it a month later, by which time you have built other features on top of the same mistake.

The test layers that matter to you as a decision-maker

You are not expected to know the technical detail, but you are expected to know what you are paying for. These are the layers any serious technical proposal should name:

Unit tests: verify the smallest pieces of logic in isolation. They are the fastest and cheapest, and they are what stops a small change from breaking an invoice total, a discount, or a tax calculation.
Integration tests: verify that the parts talk to each other and to external systems correctly — payment gateway, shipping, invoicing platforms, messaging. Most real-world failures live here, not inside the code itself.
End-to-end tests: simulate a full user journey from start to finish, from opening the page to confirming the order and receiving the notification.
Performance and load tests: answer a question no other test answers — what happens when a thousand users arrive in the same minute instead of ten? This is the layer teams skip, and then the system falls over on the day of your biggest campaign.
Security tests: scanning for common vulnerabilities before someone else finds them. The practical reference is the OWASP Top 10 list of critical web application risks; seeing it named in a test plan is a clear maturity signal.
User acceptance testing: you and your team run the system against your actual business scenarios, not against an ideal script the developer prepared. This stage is your responsibility, and no sign-off should happen before it.

Why a defect gets more expensive the later you find it

Anyone who has run a software project knows the rule: a defect caught while writing requirements is fixed by editing a sentence. The same defect caught after launch needs diagnosis, a fix, retesting, redeployment — usually plus repairing data that was corrupted along the way, and an apology to affected customers. The problem is that this gap never appears in a quote, so the vendor who cut testing out of scope looks cheaper. In reality they only deferred the invoice, and increased it.

Automated versus manual testing: when to use each

Manual testing is indispensable for judging user experience, edge cases, and anything requiring human judgment. But it cannot serve as a permanent safety net, because nobody will re-check two hundred screens by hand after every small change. Automated testing is what makes continuous development possible: you write the test once, it runs thousands of times, and it tells you within minutes if today's change broke something your team built a year ago. The practical rule: automate everything repetitive that touches money or data, and leave to human judgment everything that touches how the product feels.

Mind your test data

One issue slips past many teams unexamined: copying the production database into the staging environment so developers can test against it. That means your customers' names, phone numbers, and addresses now sit in an environment with wider access and weaker protection. Saudi Arabia's Personal Data Protection Law, overseen by the Saudi Data and AI Authority (SDAIA), governs the processing of personal data regardless of what you call the environment holding it. The fix is simple and well known: synthetically generated data, or real data with sensitive fields masked before it is copied.

What to ask your vendor before signing

A written test plan inside the scope of work, not a verbal promise that "the system will be tested".
Tests running automatically on every change through a continuous integration pipeline, with deployment blocked when a test fails.
A staging environment separate from the customer-facing one, with a clear statement of where its data comes from.
A periodic coverage report, read both as a percentage and as a direction: is coverage rising as the system grows, or falling?
A post-launch warranty period that defines what counts as a defect fixed free of charge versus a new development request.

Signs quality is being neglected on your project

You do not need a technical background to spot them: every fix breaks something else, every deployment is preceded by visible tension in the team, nobody dares touch an old module "because it works and we do not know what it would affect", and outages are reported by your customers rather than your monitoring. These are not separate problems — they are symptoms of a missing test net that would let the team change things with confidence.

At Origami we treat test coverage as part of the product, not a support line item: a system that cannot be safely modified two years in is not a successful system, however good it looked on handover day.

Software Testing and QA: Why One System Succeeds and Another Fails on the Same Budget