Why testing is an investment, not an expense
Many business owners see testing as an extra line in the budget that stretches the timeline. The numbers suggest otherwise: a bug found after deployment can cost up to 100 times more to fix than one caught during design or development.
What skipping QA really costs
Developers spend roughly 20% of their time fixing bugs. That is one day a week of firefighting instead of new features. For a company with several developers, it adds up to tens of thousands of dollars a year spent on repairs.
Developer time is only part of the bill. Each bug in a CRM or ERP system means frustrated employees, lost sales, wrong reports behind management decisions and, in the worst case, customers who stop trusting you.
The return on professional QA
Forrester research puts the return on UX improvements at 9,900%. Yes, that figure is right: every dollar spent on UX and usability testing can bring back up to $99. Among companies that introduced test automation, over 60% report a positive return within the first year, and 24% see it almost immediately.
For us, testing is part of development, not an add-on. Every system goes through two layers of checks: manual UX testing by our QA specialists, and automated tests that cover the code.
Layer one: manual UX testing through the user's eyes
Machines can't catch everything. Is the "Save" button where people expect it? Will an accountant who doesn't speak tech jargon understand the error message? Does the order process follow the order in which the business actually works? Our manual testers answer these questions.
What manual UX testing involves
A qualified tester plays the end user and walks through every path in the system. Checking that something works technically is not enough. The question is whether it works well for someone who uses it eight hours a day, five days a week.
The tester checks navigation, so users always know where they are and how to reach the function they need. They check that forms are laid out logically and field labels explain themselves. They read the error messages: each one should say what went wrong and how to fix it. And they look for consistency, so that similar actions look and behave alike across the whole system.
Scenarios built on real business processes
What separates a boutique agency from a software factory is how well it knows the client's processes. Before a tester opens the system, they get the full documentation of the workflows it is meant to support.
Take a CRM for a B2B company. The tester doesn't just check that a contact can be added. They go through the whole path: importing leads from a marketing campaign, assigning an account manager, logging later interactions, conversion, and handoff to the customer success team. At each step they ask whether the system fits the way a sales rep works or forces slow, awkward workarounds.
Reporting and working with developers
Every finding goes into the issue tracker with a precise description: what was done, what was expected, what actually happened. We attach screenshots or screen recordings, so nobody has to guess what the tester meant. The developer gets everything needed for a quick fix.
We meet regularly with the development team to go over recurring problems. If error messages in several places are too technical, we agree on a common standard for writing them in plain language. That keeps the same issue from coming back.
Layer two: automated tests and code coverage
Behind every button and form are thousands of lines of code. They have to work correctly now and also after changes made in a month, six months or two years. Automated tests are what keeps them stable.
What code coverage means
Code coverage shows what share of the source code is checked by automated tests. At 80% coverage, four-fifths of the execution paths in the program are verified every time something changes.
Automated tests find 70 to 80% of the bugs discovered during the testing phase. They run almost instantly: for the same functionality, test time can be up to 90% shorter than manual testing. And they can run hundreds of times a day at no extra cost, while every manual repeat takes someone's time.
The tests we write
We use several levels, and each checks something different.
Unit tests check single functions: does the discount calculation work, does VAT number validation reject bad input, does the lead assignment pick the right sales rep. This is the base of the testing pyramid, the fastest and most numerous kind of test.
Integration tests check how components work together: does the orders module talk correctly to inventory, does data from a web form reach the CRM database in the expected format. They catch problems at the seams between parts, which unit tests can't see.
End-to-end tests play through complete usage scenarios, much like a manual tester would, but automatically and repeatably. A browser starts by itself, clicks buttons, fills in forms and checks that the expected results appear on screen.
Continuous integration: a test run on every change
Tests don't wait until the end of the project. Every code change triggers the full test suite before it is merged into the main branch. If a test fails, the developer is told at once and fixes it before the problem spreads.
This practice is called continuous integration (CI). It shortens the time between introducing a bug and finding it. The shorter that gap, the cheaper the fix: the developer still remembers the change and can quickly find the cause.
Why you need both manual and automated testing
A fair question: if automated tests are faster and cheaper to maintain, why pay for manual testers? Or the other way round: if people can judge UX, why write automated tests? Because each covers what the other can't.
What each one catches
Automated tests are best at business logic, calculations, validation rules and integrations. They can check thousands of input combinations that would take a person weeks. But a test won't tell you whether a button has enough contrast, whether a message sounds friendly or whether the layout is intuitive.
A manual tester will notice that a form needs too many clicks, that the terminology doesn't match the client's industry language, or that a feature is buried too deep in the menu. They also find edge cases the developer didn't anticipate, because testers think like users, not like the people who built the system.
The right balance
Industry research shows a move toward balance: about 73% of organisations aim for a 50:50 split between manual and automated testing, or lean toward automation. In practice the best ratio depends on the project.
For CRM and ERP systems with a lot of business logic, we recommend high automated coverage (70 to 80%), plus manual UX testing before each major release. For applications with dynamic interfaces and frequent visual changes, the split can be more even.
What the QA process looks like step by step
Here is an example that follows one feature from start to finish.
Development: tests written alongside the code
A developer building a reporting module for an ERP system first writes an automated test that describes the expected behaviour: "For sales data from the last quarter, the report should contain total revenue, transaction count and average order value." Only then do they write the code that delivers it. This approach is called test-driven development (TDD), and it forces the requirements to be thought through before coding starts.
When the implementation is done, the developer runs all tests for the reporting module locally. If they pass, the code goes to the repository, where the CI system runs the project's complete test suite. Any failure blocks the next steps and has to be dealt with immediately.
Manual testing: checking the user experience
Once the new feature passes the automated tests, it goes to the manual tester. The scenario comes from a real use case: "As a CFO, I want to generate a quarterly report for the board, export it to PDF and email it to board members."
The tester goes through the scenario and documents each step. Is the report data clearly formatted? Do the charts have sensible axis labels? Does the PDF keep its layout on different paper sizes? They also look at the small things: is the export button easy to find, does the user get a confirmation when the operation finishes, does a progress indicator appear for large datasets.
Fixes and retesting
Findings go into the issue tracker with priorities. Critical bugs (the system won't generate reports) block the release. Medium ones (wrong date format) must be fixed before deployment. Suggestions (add a keyboard shortcut) go to the backlog for later iterations.
After the fixes, the tester retests to confirm that the issues are gone and that the fixes didn't break anything else. Deployment happens only after this cycle ends successfully.
What you get from an agency with a real QA process
Choosing a software vendor is about more than price and portfolio. How a company treats quality affects your experience as a client and the long-term value of what you paid for.
Fewer surprises after go-live
A system that has passed both layers of testing reaches users ready for real work. No amount of testing guarantees zero bugs, but it brings their number and severity down to a level that doesn't disrupt daily operations.
Faster changes later
Solid automated coverage gives developers confidence when they change things. Say you want to add a module or connect another tool six months from now. They can do it without worrying about breaking something that worked, because the tests check existing functionality automatically.
Documentation that stays current
Well-written tests also describe how the system behaves. A new developer can read them to learn the business rules and the expected behaviour of each module. That helps a lot when a system is maintained and extended for years.
Quality is built on purpose
Testing doesn't slow down delivery. It is what makes the result last. Manual UX testing together with automated coverage gives you a system that works correctly and also fits the way people actually work in it.
A boutique agency can give each project attention that large software factories can't. Our testers learn the specifics of your industry and processes. Our developers write tests with long-term maintenance in mind. The result is software that serves your company for years instead of producing a steady stream of problems.
If you're planning a custom CRM, an ERP system or business process automation, get in touch. We will go through your needs and propose a solution that passes thorough testing before it reaches your employees. The first consultation is free.
