Testing and Quality Assurance for Business Apps: A Pragmatic SME Guide

A bug that sends hundreds of duplicate invoices to your clients. A calculation applying the wrong VAT rate for two months. A form that wipes data instead of saving it. None of this is far-fetched: it's what awaits any business application whose testing was neglected.

The later a bug is found, the more it costs to fix: it's one of the oldest and most consistent findings in software engineering. Yet testing is often seen as a "luxury" an SME can't afford. In reality, it's the lack of testing that's expensive.

This article covers the 4 essential test types, how to estimate a bug's real cost, and a pragmatic testing strategy suited to SME budgets.

Key takeaways

• A bug costs more the later it's found: during design it's a comment; in production it's data to fix and clients to reassure.
• Four test types complement each other: unit and integration tests (automated), user acceptance (manual), and performance tests.
• Focus effort where a bug can do the most damage: financial calculations, payments, data changes, access rights.
• Every fixed bug should get a test so it doesn't come back.
• Automations need testing too: on real past cases, then with human validation, before you hand them hours of work.

The real cost of a bug

The 1-10-100 rule

This rule of thumb, widespread in quality management, sums up a reality: the cost of fixing a defect rises sharply at each stage it goes unnoticed. The values below are relative orders of magnitude, not actual amounts:

Examples of costly bugs in SMEs

Illustrative examples: real impact depends on your business.

• Duplicate invoices — A few hours of technical fixing, then a day of follow-ups and apologies to the clients affected, and a dent in trust
• Margin calculation error — Months of wrong figures and decisions made on bad data
• Client data breach — Notification to the data protection authority if the breach poses a risk, informing the people concerned, an audit, GDPR remediation

The 4 essential test types

1. Unit tests (automated)

What: each function in the code is tested in isolation. The "calculate price including VAT" function receives a pre-tax price and a VAT rate, and the test checks the result.

Why essential: unit tests catch logic errors before they reach users. They run in seconds and replay with every code change.

Recommended coverage: most of the critical business code (calculations, validations, data transformations) — often 60–80%.

2. Integration tests (automated)

What: they check that components work correctly together. Does creating a quote properly update stock, send an email, and write to the log?

Why essential: a function can work perfectly alone and fail alongside others. Integration tests also check the connections with your other tools.

Recommended coverage: your application's critical paths (often around ten).

3. Acceptance tests (manual)

What: end users test the application in real conditions. A salesperson creates a real quote, an accountant approves a real invoice, a technician enters a real job report.

Why essential: automated tests can't tell whether the ergonomics make sense, whether labels are clear, or whether the journey is smooth.

Recommendation: 1–2 weeks of acceptance testing with a few users from each profile before going live.

4. Performance tests (automated)

What: load simulation to check the app stays fast. What happens when 50 users log in at once? When the database holds 100,000 records?

Why essential: an app that works with 5 users and 1,000 records can collapse at real scale. Cloud hosting offers flexibility, but the code must be optimized.

Recommendation: test with 2–3× the expected users and data volume.

Comparison: with and without a testing strategy

Test an Automation Before Handing It Hours of Work

The same principles apply to automations — even more so when they use AI. Before letting a flow read your invoices or reply to your clients, you need to know how reliable it is on your own cases.

Our method is simple: replay the automation on a sample of real past cases (for example a hundred invoices already entered, or messages already handled), compare its output with what a person did, measure the error rate, then go live with human validation before gradually letting it run on its own for simple cases. Every action is logged.

That's how you get hours back without taking risks, whether for document processing or customer message replies — a central topic for an e-commerce business, for instance.

The pragmatic testing strategy for SMEs

Recommended budget

A commonly used order of magnitude: 15–20% of the development budget for testing. For a €30,000 project, that's €4,500–6,000.

It isn't an extra cost — it's a saving: without tests, a large share of the annual budget goes into emergency fixes; with tests, it can go into improvements.

The test pyramid

The classic distribution (wide base, narrow top):

1. Base — Unit tests (the majority) — Fast, numerous, covering every calculation and validation
2. Middle — Integration tests — Checking critical end-to-end paths
3. Top — Manual tests (a small share) — User acceptance, exploratory tests, ergonomic checks

When to test?

• At every release — Automated tests run before every deployment through continuous integration (CI)
• After every fix — A fixed bug = a test added so it doesn't return (non-regression)
• Full acceptance — Before every major version
• After security updates — Framework updates can introduce regressions

Testing in CI/CD pipelines

Modern development builds testing into the deployment pipeline:

1. A developer pushes code → automated tests run (a few minutes)
2. If any test fails → deployment is blocked and the developer is notified
3. If all tests pass → code moves to a staging environment
4. Acceptance testing on staging (manual)
5. Final deployment to production

This automation means far fewer bugs reach production unnoticed. The maintenance burden drops because problems are caught at the cheapest moment.

The test coverage sweet spot

Don't chase 100% coverage. Focus testing where a bug would do the most damage:

Common mistakes to avoid

1. "We'll test later" — Later never comes. Tests are written alongside the code
2. "The developer tested it, that's enough" — The developer checks that it works; the user checks that it makes sense. Both are needed
3. "We don't have the budget" — A production bug costs far more than a test
4. "We need 100% coverage" — Unnecessary and counterproductive. Strong coverage of critical code beats 100% everywhere
5. "Tests slow development down" — A little, at first. Then they speed things up: fewer bugs, fewer regressions, calmer releases

Our approach at Iselia Projects

At Iselia Projects, testing is part of every project.

1. Unit tests — Critical business functions are tested automatically
2. Integration tests — Critical paths and connections with your tools are validated end to end
3. Guided acceptance — We provide a structured test plan for your users
4. Post-launch monitoring — Automatic error detection and alerts
5. Non-regression principle — Every fixed bug is covered by a test. Our maintenance keeps that coverage up over time

Discover our support plans →

Acceptance testing checklist

Use this checklist for structured acceptance testing before going live:

• All critical business workflows tested end to end (create, edit, delete, search)
• Edge cases checked (empty fields, maximum lengths, special characters)
• Role-based access tested for each profile
• Email notifications triggered correctly
• Data export/import working
• Performance acceptable under realistic load (main screens respond in about a second or two)
• Mobile/tablet display checked if relevant

Conclusion: testing isn't a luxury

Quality assurance isn't a cost center — it's insurance against costly bugs, data loss, and users rejecting the tool. The later a bug is found, the more it costs.

The pragmatic SME strategy is simple: a proportionate testing budget, priority on critical business code, acceptance with real users — and, for automations, a test on your real cases before handing them any work.

Your app or automations lack a testing strategy? At Iselia Projects, the assessment is free and with no commitment: in 30 minutes, we review your repetitive tasks and your tools, then estimate the hours you could get back. Book your free assessment →