Automated Software Testing — Guide for Non-Technical Founders
Every client asks: «why does testing cost so much?» The short answer: a bug in production costs 10-100x more than the test that would have caught it. The long answer: testing isn't an add-on cost — it's insurance. Here's what you actually get when you pay for automated testing and how to recognize a team that tests well.
What software testing is (and isn't)
Testing means verifying that the application does what it should, under the conditions it should. Two approaches exist: manual (a person clicks through the app and checks) and automated (code written specifically to run checks in seconds, hundreds or thousands of times per day).
Manual testing has its place — for UX, for exploration, for visual verification. But it doesn't scale. If you have 200 features and make a change, a human tester can't manually verify all 200 before every release. Automated tests do exactly that: they run in 30 seconds and tell you «100% of checks pass» or «3 tests failed, here's exactly where».
What testing is NOT: handing the app to friends to «try it out for a bit». Their feedback is valuable for UX, but it's not testing. It doesn't reproduce production conditions, doesn't verify edge cases, and doesn't run repeatably.
The three types of automated tests
Any serious team uses three levels of tests. Each catches a different kind of problem:
| Test type | What it verifies | Execution time | Code coverage |
|---|---|---|---|
| Unit tests | A single function or module in isolation | Milliseconds | Most |
| Integration tests | Modules communicating with each other (API + DB, frontend + backend) | Seconds | Medium |
| End-to-end (E2E) | Complete user flow, from login to checkout | Minutes | Fewest in number, closest to reality |
Unit tests — the foundation
A unit test takes a function, gives it a specific input, and verifies the output is correct. For example: the function that calculates the discounted price. The test gives it price 100 RON and discount 20%, and checks the result is 80 RON. Then it gives price 0 RON and discount 50% and checks the result is 0, not an error. Then a negative price and checks the function rejects the input.
Unit tests are the fastest (thousands run in under 10 seconds), the cheapest to write, and the most stable. A good team has 70-80% of code covered by unit tests.
Integration tests — verifying the connections
Each function can work correctly on its own, but when the API sends data to the database, and the database returns a different format than expected, the app breaks. Integration tests verify exactly these contact points. They run slower (they start the database, make real HTTP requests), but they catch problems unit tests cannot see.
End-to-end tests — simulating the real user
An E2E test opens a real browser, navigates to your site, clicks «New Account», fills out the form, clicks «Pay», and verifies the order appears in the admin dashboard. It's the closest thing to what a real user experiences. The downside: they're slow (minutes, not seconds) and fragile (a minor network delay can cause a false failure). A good team uses E2E selectively — only for critical flows (checkout, registration, payment), not for every page.
Why it matters — the real cost of bugs
A bug caught during development costs an average of €5-€50 to fix. The same bug in production costs €500-€5,000: diagnosis time, lost sales during downtime, customer support, and sometimes hard-to-quantify reputational damage. The difference is 10-100x.
Concrete examples from the market:
- Online store with a broken checkout — 8 hours of downtime on Black Friday = dozens of lost orders. The bug: a validation that rejected cards issued by a specific bank. An integration test would have caught it.
- Mobile app that failed to sync data — users lost offline orders. Fixed after 3 days of complaints and 1-star App Store ratings. An E2E test would have caught it before release.
- Payment integration sending duplicate invoices — discovered only at fiscal audit, 6 months later. A unit test on the retry function would have caught it on the first run.
How to evaluate whether your team tests well
Here's the practical part. Even if you don't write code, you can assess testing quality from three concrete signals:
- Ask to see the CI pipeline. «CI» means continuous integration — a system that runs all tests automatically on every change. If the team has CI configured (GitHub Actions, GitLab CI, or another runner), they test regularly. If they «run tests manually when they remember», they don't test regularly.
- Ask for the coverage report. Coverage is the percentage of code reached by tests. Above 70% is good. Below 40% means large portions of the app aren't verified automatically. Zero means no automated tests exist at all.
- Ask what happens when a test fails. The correct answer: «The build is blocked, no deploy until it's fixed.» The wrong answer: «We ignore them and fix them when we have time.» Tests that are ignored aren't tests — they're a false sense of safety.
How much testing costs — real numbers
Testing adds development time. The empirical rule: 15-30% of total project time goes to writing and maintaining tests. This isn't waste — it's the cost of prevention.
| Project type | Dev budget | Testing cost (15-30%) | What it prevents |
|---|---|---|---|
| Brochure site (5 static pages) | €2,000 – €5,000 | €300 – €1,500 | Broken links, mobile layout issues |
| Online store (WooCommerce/Shopify) | €5,000 – €20,000 | €750 – €6,000 | Broken checkout, wrong prices, negative stock |
| SaaS web app (custom) | €15,000 – €60,000 | €2,250 – €18,000 | Lost user data, duplicate payments, unauthorized access |
| Mobile app (React Native / native) | €10,000 – €40,000 | €1,500 – €12,000 | Crashes on specific devices, offline sync failures |
| Payments / FinTech | €30,000 – €150,000 | €4,500 – €45,000 | Wrong transfers, PSD2 compliance failures |
For critical projects (payments, personal data, legal compliance), testing isn't optional — it's a contractual and sometimes legal requirement. PSD2, GDPR, and SOC 2 all require evidence of testing.
When it does NOT make sense to invest heavily in tests
Here I need to be honest. Not all projects need full test suites:
- Validation prototype — if you're building a demo that will be thrown away in 2 weeks, tests are waste. The goal is to learn, not to be robust.
- Simple landing page — a static HTML page with no logic has nothing to break. Visual verification is enough.
- Experimental feature — if you don't know whether you'll keep the feature, write the test after you decide it stays.
The rule: write tests for code that stays in production for more than a month and whose breakage generates cost. Everything else is excess.
Testing in practice — what you should see from your team
A team that takes testing seriously has the following in place:
- A green CI pipeline. On every commit, tests run automatically. Green means «all pass». Red means «no deploy until fixed».
- Tests before new features. The developer writes the test for the new behavior first, then implements the code that makes it pass. This is called TDD (test-driven development) and reduces bugs by 40-60% according to industry studies.
- Regression tests. When a bug is found in production, a test is written that reproduces it, then the code is fixed. That specific bug will never recur — the test will catch it.
- Production monitoring. Tests prevent, but can't catch everything. Sentry or a similar tool catches errors that reach users and reports them in real time.