We love to pretend that business apps are boring. Predictable. Safe. Low risk. After all, we’re not launching rockets or handling billions of users… we’re just managing leave requests, budgets, logistics, workflows, customer data, and access rights. You know, just the things entire companies run on. But here’s the uncomfortable truth:

Business apps are some of the riskiest systems we build

And they’re often the least well-tested. If they get tested at all (and no Kyle, I don’t mean you to click through the app that you’ve build and notice that it works like a charm).

So if you are in a project, where you do in fact test business apps, they’re the most likely to be surrounded by quality theater. Mock data. Manual clicks. Acceptance criteria that describe buttons, not outcomes. Test suites that proudly show 95% coverage - and miss the fact that login fails for half the users in production.

The illusion of safety in business apps

Enterprise apps are integration-heavy. They pull data from ERPs, sync with CRMs, push records into legacy systems, and serve users with a dozen different roles. They’re built with multiple layers of logic: some in code, some in workflows, some in config, some in Excel sheets no one wants to admit still matter.

And we test them with… stubs. And mocks. We spin up test environments with sanitized data and assume it’ll behave the same as production. We run a few UI flows and declare victory. It looks good. Until real users do real things. That’s when a renamed field in SAP breaks a Power Automate flow. Or a SharePoint permission issue locks out an entire department. Or a regulatory field gets left blank because no one ever tested the edge case where null means non-compliant.

Stubs, mocks, and hope

Most business app testing is built on mocked dependencies. We fake the response of an API. We stub out the database. We hardcode sample user roles. That’s fine for unit tests. It’s even useful when isolating tricky logic. But in business systems, the logic is rarely the problem. The integration is. You’re testing how your leave request process reacts to 5 days off, but not how it handles a broken HR system, or how it syncs to payroll, or what happens when a manager’s access level was misconfigured six months ago.

Mocks don’t test reality. They test assumptions.

And assumptions, as we all know, are the mother of all f*ck-ups.

Quality theater vs. real risk

Most test coverage in business apps tells you that code was executed, not that value was delivered. You might have 100 tests on a plugin, but none on the actual sales process. You’ve tested that the invoice PDF renders, but never validated the tax calculation logic that runs when the customer is in a different country. Meanwhile, nobody’s tested accessibility in your custom forms. Or what happens when your dependency times out. Or whether your data policies are enforced when users export records in bulk. But hey — the test coverage is 91%. Green dashboard. All good, right?

Low-code makes it easier to build — and easier to forget what comes next

Low-code platforms like Power Platform let teams move fast. They remove boilerplate. They open the door for non-developers to build real solutions. And they often work beautifully, until they don’t. The problem isn’t the platform. It’s what happens after the prototype. In many low-code environments, testing is either entirely manual or completely absent. Automation is rare. Pipelines are an afterthought. Real-world data is never tested. Why? Because the person who built the app is usually not a professional developer. They’re a domain expert. A problem-solver. A builder. They created something great, because no one else was going to. But now the business depends on it. And suddenly, this scrappy solution is infrastructure.

Here’s the part nobody likes to say out loud:

Making the baby is the fun part.

Raising it: maintaining it, securing it, testing it, governing it, is less glamorous. It’s not exciting anymore. It’s responsibility. And the person who built it? They’ve moved on. Or they’re overwhelmed. Or they were never trained to do long-term maintenance at scale. That’s how you end up with business-critical systems running untested, unmonitored, undocumented, and unowned. We have to stop pretending low-code means low-risk. If it runs your business, it deserves real engineering practices. And real testing.

So what do you do?

First: acknowledge the danger zone. Business apps may look simple on the surface — but they’re full of integration, compliance, and user-specific behavior that make them fragile.

Then: test what matters. Start writing tests. But write fewer unit tests; write smarter integration tests. Test using real data patterns, not lorem ipsum. Validate API contracts, user roles, error flows, edge cases, and accessibility. Use tools that can test what actually happens — not just what’s supposed to.

And finally: shift left. Bring QA into the requirements. Make behavior testable before the code exists. If a business rule can’t be verified, it’s not ready to build.

Conclusion: If it looks boring, look again

The apps that look least exciting are often the most dangerous. Because we don’t give them the testing rigor they need. Because we assume low complexity where there’s actually high risk. Because we tape quality on at the end and hope it holds. And then we wonder why production keeps breaking after the “green” deploy.

It’s time to stop pretending business apps are safe. They’re not. But they can be — if we start testing like they matter.

This blog post is part of a series on testing software. You can find more parts here:

• Your Testing strategy is broken - Let’s fix it
• The benefits of testing (beyond working apps)