How to Review and Test a Custom Business System Before You Accept It

The developer tells you the system is ready, and the invoice for the final payment is on your desk. This is the moment most owners of a custom business system are least prepared for: you are being asked to accept something you were never taught how to check. Acceptance testing is how you do it. It is not a technical exercise. It is you and your team using the system the way your business really works, before the work is declared finished and the last payment falls due. This guide shows a non-technical owner how to run it, step by step.

What acceptance testing is, and what it is not

Acceptance testing is the stage where the business confirms that the finished system does what was agreed, using real work rather than a demonstration. You will often see it called user acceptance testing, or UAT. The word "user" matters: the people who judge the system are the people who will use it, not the people who built it.

It helps to be clear about what it covers and what it does not:

• It is not the developer's own testing. A developer checks that the software runs without errors and that each feature behaves as the developer designed it. Acceptance testing checks something different: whether what was built matches what your business needs.
• It is not a chance to add new ideas. Wishes that were never part of the agreed scope are changes, and they are priced and scheduled separately. Mixing them into the test is the fastest way to turn a clean sign-off into an argument.
• It is not a code review. You do not need to read a line of code. You are judging results: what goes in, what comes out and whether it is right.
• It is not optional. If you skip it, you are accepting the system on trust, and the first real test will happen on live customers and live records.

Where this stage sits in the schedule, and how long projects of different sizes tend to take, is covered in how long a custom business system takes. This guide is about what to do inside that stage.

Why the owner has to do it, not the developer

The person who built a system is the worst person to test it. A developer knows exactly how each screen is meant to be used, so they unconsciously follow the path they built. They do not know that your Friday stock count always has three exceptions, that one customer has two company names, or that your counter staff enter orders with one hand while serving someone else.

There is also a practical reason. Acceptance is the point at which the project changes hands from "being built" to "finished". Before it, the developer is working to fix things. After it, problems tend to be treated as support requests or new work, depending on what your agreement says. That makes this the moment when you have the most influence, and the moment when a careful check costs you least.

This is why the payment schedule matters. A sensible quote links the final payment to your chance to test the system against what was agreed, not to a calendar date. If you are still comparing suppliers, our guide to comparing two custom software quotes shows how to check this before you sign.

Step one: agree what "done" means before the test starts

You cannot pass or fail a system against a feeling. Acceptance criteria are short, written, checkable statements of what the finished system must do. Ideally they come straight from the scope in your quote. If the scope was written loosely, turn it into a list now and agree it with the developer in writing before testing begins, so both sides are working to the same page.

The test of a good criterion is simple: could two different people check it and reach the same answer? The table below shows how vague wording becomes something testable.

Keep the list to what was actually agreed. Anything you think of during testing that is not on the list goes into a separate "new requests" column, which you will meet below. Ten to thirty clear criteria are usually more useful than a hundred fuzzy ones.

Prepare real tasks and realistic data

A system that works on tidy sample data can still fail on your business. Build your test from the real week, not from the ideal one.

• Write scenarios from a normal week. List the eight to twelve things your business actually does with the system. For each, note who does it, what they start with, what they do and what should happen at the end.
• Include the awkward cases. Refunds, cancellations, part deliveries, a price that changes midweek, a customer record entered twice, an order started and abandoned. Systems usually fail on exceptions, and exceptions are most of real work.
• Use real or realistic data. A few dozen genuine-looking records in different shapes will find more problems than a handful of perfect ones. If you use copies of real customer records, limit who can see the test copy, and ask the developer how it is kept separate and who has access.
• Check moved data against its source. If your existing records were loaded into the new system, take a sample and compare each field with the original spreadsheet or old tool. Moving your data into a new system explains what to prepare and what usually goes wrong.
• Ask for a separate test copy. Testing should happen on a copy that is kept apart from live records, so that practice orders and mistakes never reach real customers. Ask the developer how this will be set up.

Choose who tests it

Acceptance is only meaningful if the right people do it. The owner or manager should take part, but the system should also be tried by the people who will use it every day.

• One person from every role. If the system has cashiers, supervisors, a warehouse team and an owner view, each role should test its own screens. Different roles see different things, and each login needs its own check.
• At least one sceptic. The staff member who likes the old spreadsheet is useful. If the system satisfies them, it will probably satisfy others.
• Protected time. Testing squeezed between customers produces rushed, polite results. Set aside a block of time, even if it is only a few hours spread over some days.
• Permission to be difficult. Tell testers that finding problems is the job. A tester who says "it seems fine" to avoid awkwardness is worse than none.
• One person who gathers the results. Several people reporting by message in different ways makes the developer's job hard. One owner of the list keeps it consistent.

If the system is shared across several outlets or branches, test at least one outlet's real routine end to end. A multi-site setup adds its own checks, such as whether each branch sees only its own data. The multi-outlet management guide covers what to look for.

Run the test: a simple routine

You do not need special tools. A shared spreadsheet, a notes document and a phone for screenshots are enough. Work through the scenarios in a fixed routine:

• Step 1: confirm what is being tested. Ask the developer which version you are testing and to tell you if it changes mid-round. Results mean little if the system keeps shifting under the testers.
• Step 2: walk each scenario in order. Record pass or fail against the criterion. For every failure, write down the exact steps, what happened and what you expected, and take a screenshot.
• Step 3: try to make mistakes. Leave required fields blank, type a letter where a number belongs, press back, refresh the page, enter the same thing twice. A good system tells the user what went wrong.
• Step 4: check every output. Reports, exports, printed documents, emails and notifications are what the business actually relies on. Compare their figures with what you know to be true.
• Step 5: test two people at once. If several staff use the system together, have two of them work on the same item or the same stock at the same time and see what happens.
• Step 6: close a day or a month. Run the end-of-period routine on the test data and check that the totals agree with what you entered.
• Step 7: send everything in one batch. Hand the developer a single organised list rather than a trickle of messages.

Keep a punch list, and sort it honestly

A punch list is a numbered record of every issue found, kept in one place. Give each item a number, the scenario it came from, the steps to repeat it, what happened, what you expected, a screenshot and a status such as open, fixed or retest. A list like this turns "it does not work properly" into something a developer can act on, and later proves what was raised and when.

Not every item is the same kind of problem, and treating them as equal is how projects stall. Sort each item as you log it:

The last row is the one that causes the most friction. Something that does not meet the agreed list is a fault. Something you would like that was never agreed is a change. Both belong on the list, but labelled differently, so the disagreement, if there is one, happens in writing and early. It also helps to know in advance how your quote treats each, which is why the after-launch terms are worth reading closely.

Retest, then sign off in writing

Fixing one thing can quietly break another. After the developer works through the list, retest every item that was fixed, then rerun your core scenarios to make sure nothing nearby has changed. Keep going until the items that block work are cleared.

Then make a decision, and make it explicit. There are only three honest outcomes:

• Accepted. Every agreed criterion passes.
• Accepted with listed exceptions. Minor items remain, each written down with an owner and an agreed handling, such as a fix by a stated date or a place on the change list.
• Not accepted. One or more blocking items remain. The punch list becomes the agenda for the next round.

A written sign-off should say which version was tested, the date, who tested it, which criteria passed, and exactly which items remain open and how each will be handled. It should be given by the person in the business with authority to accept it. Verbal approval in a hallway is how disputes start.

Before you sign, also check what comes with the system. The handover should include the logins, the documentation and the accounts the system runs on, in your business's name where that was agreed. Who owns the source code of your custom business system explains what to confirm. Release the final payment against the payment terms you agreed, and only once you are satisfied that the sign-off matches what you tested.

A reusable acceptance checklist

Copy this table into a spreadsheet and add a result column for each area. Anything that is not confirmed becomes a line on the punch list.

Common mistakes

• Letting the developer run the test. A demonstration shows the system working the way it was designed to work. It does not show how it behaves in your hands.
• Testing only the happy path. If every scenario goes smoothly, you have tested very little.
• Using tidy sample data. Perfect records hide the problems that messy real ones expose.
• Leaving the real users out. If only the owner tests, the people who must live with the system find the faults after go-live.
• Mixing wishes with faults. A new idea reported as a bug confuses the list and damages trust on both sides.
• Agreeing by message and memory. Without a written list of criteria and a written sign-off, nobody can later show what was accepted.
• Signing under time pressure. A launch date is not a reason to accept a blocking fault. Record the exceptions, or delay the sign-off.
• Paying before you have tested. Check that the payment terms give you a real chance to test first.

Where Gotka Technologies fits

Gotka Technologies' App & System Development service builds web apps, business systems and mobile apps, with indicative starting prices of RM8,000 for web apps and dashboards, RM12,000 for business systems and integrations and RM15,000 for mobile apps, each confirmed by a written quote once the scope is known. How acceptance testing works on any project, including how many rounds of fixes are covered and how payments relate to sign-off, belongs in that written quote, so ask for it in writing from every supplier you talk to, including us. To judge the price side first, see our mobile app cost guide, and if you are still deciding between buying and building, read off-the-shelf vs custom software. The finished system also needs a dependable place to run, which is where Gotka's Cloud Hosting comes in.

Key terms used in this guide

• Acceptance testing: the stage where the business tests the finished system against what was agreed, before accepting it.
• UAT (user acceptance testing): acceptance testing carried out by the people who will use the system.
• Acceptance criteria: written, checkable statements of what the finished system must do.
• Test scenario: a realistic task, written out step by step, with the result you expect.
• Test data: the records used during testing, ideally real or realistic in shape.
• Punch list: a numbered record of every issue found during testing, with its status.
• Defect: something that does not do what was agreed.
• Change request: a request to add or alter something that was not in the agreed scope.
• Retest: checking again that a fixed item now works and that nothing nearby has broken.
• Sign-off: the written confirmation that the business accepts the system, including any listed exceptions.