Agree what must be proven before sign-off

Testing business software means verifying that the system does what your operations require, handles errors gracefully, and protects your data. Unlike consumer-facing products where a rough edge might go unnoticed, a fault in a CRM, portal or internal workflow can halt invoicing, expose personal data or corrupt records that take weeks to untangle.

The first distinction to understand is who tests what. Developers run technical tests on the code they write: checking that individual functions behave correctly and that different parts of the system talk to each other as expected. That work sits outside your direct involvement, but it does not replace the testing your business needs to do. Business testing confirms that the finished system supports your actual processes, not just that the code compiles without errors.

Every test you run should trace back to a written requirement or acceptance criterion. If a behaviour was never specified, you cannot reliably claim it works or does not work. Before testing begins, check that your requirements document or specification covers the normal path through each process, the permission boundaries for each role, and what should happen when something goes wrong — a rejected payment, a missing file, a duplicate record.

Testing environments

Business software should be tested in an environment that mirrors production as closely as possible. That means the same server configuration, the same database engine and the same integration connections. Testing against a local setup on a developer's machine gives false confidence because infrastructure differences frequently cause failures that code-level tests never catch.

You will typically need at least two non-production environments: one for the development team to deploy and re-deploy frequently, and a staging environment that is locked down for your business testing. The staging environment should only change when a release candidate is ready for your review. Ask your supplier to confirm the environment topology before testing starts, and check whether third-party integrations are connected to sandbox accounts rather than live ones.

Types of testing relevant to business systems

  • Functional testing: Does each feature do what the specification says?
  • Integration testing: Does data flow correctly between your system and external services such as payment gateways, accounting software or email providers?
  • Permission testing: Can each role only see and do what their access level allows?
  • Data-migration testing: Has historical data been moved accurately, completely and without duplication?
  • Performance testing: Does the system respond acceptably under your expected user load and data volume?
  • Regression testing: Do existing features still work after a change or fix?

User acceptance testing, which is the formal stage where you sign off on the work, is a distinct phase with its own structure. This guide covers the broader testing activity that leads up to that point and runs alongside it.

Testing a CRM system

A CRM holds your customer relationships, so the priority is data integrity and process completeness. Test the full lifecycle: creating a contact, converting it to an opportunity, moving it through each pipeline stage, generating a quote and closing it. Check that mandatory fields are enforced, that duplicate-detection works when two users enter the same company simultaneously, and that reporting figures match the underlying records. Pay particular attention to what happens when a record is deleted or archived — are related tasks, notes and attachments handled consistently?

Testing a customer portal

Portal testing centres on identity and access. Create test accounts for each role — customer, account manager, administrator — and verify that each one sees only the correct documents, orders or support tickets. Test the login and password-reset flows, including expired-session behaviour. If the portal allows file uploads, test with files at the maximum permitted size and with unexpected file types. Check that actions taken in the portal appear correctly in your back-office system if the two are connected.

Testing an admin panel

Admin panels are often treated as an afterthought during testing, yet they control the configuration your users depend on. Test every settings screen: changing a threshold, toggling a feature on or off, updating notification email addresses. Verify that changes take effect immediately or after the expected delay. Test what happens when an admin enters invalid data into a configuration field — the system should reject it clearly, not silently fall back to a default.

Testing integrations

Integration testing requires careful sequencing. Start by confirming that each connection is authenticated and that the system can reach the external service. Then test the individual data flows: pushing an invoice to your accounting software, pulling a stock level from your warehouse system, sending a notification via your email provider. After that, test failure scenarios: what does your system do if the external service is down, returns an unexpected error code or times out? Does it retry appropriately, queue the action or alert an administrator?

Testing data migration

If your project includes moving data from a legacy system, migration testing deserves its own structured approach. Agree record counts with your supplier before the migration runs. After each test migration, compare source and destination counts at the record level and at the field level. Spot-check individual records for formatting issues — dates, currency values, special characters and truncated text are common failure points. Run the migration more than once to confirm it is repeatable, and test the rollback procedure in case you need to revert.

Testing without a dedicated QA team

Many businesses commissioning custom software do not have a test department. In that situation, testing falls to the people who understand the processes: operations managers, finance staff, customer-service leads. This works, but it requires time to be ring-fenced in the project plan. Do not expect people to test thoroughly between their normal duties. Schedule dedicated testing windows, provide a clear list of scenarios to work through, and ask testers to record what they did and what they saw — even when the result was correct. A written trail prevents disputes about whether something was tested or not.

Testing only the happy path

The single most common mistake is running through each process once, in the ideal order, with correct data, and declaring it done. Most defects appear in edge cases: submitting a form with missing optional fields, navigating backwards through a multi-step workflow, performing the same action twice in quick succession, or using data that contains spaces, accented characters or unusually long strings. Your test scenarios should explicitly include error conditions and unusual but valid inputs.

Not defining pass and fail before testing

If you do not agree what "done" looks like before testing starts, every defect becomes a negotiation. Acceptance criteria should be written before development begins, not after a problem is found. When a test fails, the criterion tells you whether the system is genuinely broken or whether the requirement was ambiguous. Ambiguous requirements should be clarified and documented, not resolved by verbal agreement in a meeting.

Ignoring data volume

A system that responds instantly with fifty test records may slow to a crawl with fifty thousand. If your business software will hold years of transaction history, test with a dataset that reflects that volume. Ask your supplier to generate or anonymise production-scale data for the staging environment. Performance issues discovered after go-live are significantly more expensive to fix than those caught during testing.

Skipping regression testing

When a defect is fixed, the instinct is to check only the specific issue. However, the fix may introduce a new problem in a related area. Regression testing means re-running a selection of previous tests to confirm that nothing else has broken. You do not need to repeat every test every time, but you should maintain a core set of scenarios that cover your most critical processes and run those after each change.

Testing against moving targets

If requirements are still being changed while testing is underway, your test results become unreliable. A feature that passed yesterday may fail today because the underlying logic was altered. Agree a feature freeze for each testing cycle: no changes to the scope of what is being tested until that cycle is complete. New ideas and change requests should be logged for the next cycle, not slipped into the current one.

Key checks before sign-off

  • Every requirement in the specification has a corresponding test result recorded as pass, fail or blocked.
  • All fail and blocked results have been resolved or formally deferred with a documented reason.
  • Permission testing covers every role, including any custom roles created during the project.
  • Data migration has been run at least twice with consistent results.
  • Integration failure scenarios have been tested and the system's behaviour documented.
  • Backup and restore procedures have been tested on the staging environment.
  • Known limitations have been listed in writing and accepted by the business.
  • Access credentials for the production environment have been confirmed and secured.

Limitations of testing

Testing can demonstrate the presence of defects. It cannot prove their absence. No matter how thoroughly you test, there is a residual risk that a combination of conditions you did not anticipate will cause a problem in production. The purpose of structured testing is to reduce that risk to an acceptable level, not to eliminate it entirely. Your contract and support arrangements should reflect this reality by covering defect resolution after go-live within agreed parameters, rather than assuming testing will catch everything.