User acceptance testing explained for business owners

Quick answer

User acceptance testing, or UAT, is the step where you and your team check delivered software against the agreed specification, using realistic data, before you formally accept it. It is done by the people who will use the software and is planned directly from the specification, one test for each requirement. When you pay after acceptance, UAT is the step that decides whether a delivery is ready to be paid for.

What UAT is

Software usually passes through several kinds of testing before it reaches you. Developers test their own code as they write it. A tester on the delivery team checks that features work and that nothing already built has broken. A senior reviewer checks the design and the code.

UAT comes last, and it answers a different question. The earlier checks ask whether the software works as the team built it. UAT asks whether it does what you agreed it would do, in the way your business actually works. A purchase order screen can pass every technical test and still fail UAT because your stores manager needs to record partial deliveries and the screen only allows full ones.

That is why UAT belongs to the buyer. The delivery team can help you prepare for it, and it remains your decision.

Who does it

The best testers are the people who will use the software every day. For a job card system in a Rajkot engineering firm, that means the supervisor who creates jobs, an operator on the shop floor, and the accounts person who raises invoices from completed jobs. For a WhatsApp booking flow at an Ahmedabad clinic, it means front desk staff and a couple of willing patients.

Name one person as the UAT owner. Their job is to plan the tests, make sure each one is run, collect the results and make the recommendation to accept or send back. In a small business this is often the owner or a senior manager. In a product company it is usually the product owner.

Keep the group small. Three to five people who know the work well will find more useful issues than twenty people clicking around without a plan.

Planning UAT from the specification

A good UAT plan is written straight from the specification. Each requirement in the specification becomes one or more test cases. If a requirement cannot be turned into a test, it was too vague, and that is worth fixing in the specification before the work is built. The specification starter is designed with this in mind, so each line can be tested.

Writing a test case

A test case needs four parts:

• Requirement: the line of the specification it checks
• Steps: what the tester does, in order
• Test data: the records or inputs to use
• Expected result: what should happen if the requirement is met

Here is an example for a dealer ordering app for a Surat textile trader.

| Part | Content | |---|---| | Requirement | A dealer can place an order for any in stock fabric, and the order total includes GST | | Steps | Log in as a test dealer, add three fabrics to the cart, place the order | | Test data | Dealer account in Gujarat, three fabrics with known prices and GST rates | | Expected result | Order is created, stock reduces, total matches the calculated figure, dealer receives a confirmation on WhatsApp |

Covering the unhappy paths

Most buyers test what should happen when everything goes right. Spend some time on what happens when it goes wrong. What if the dealer orders more than is in stock? What if the payment fails halfway? What if two staff edit the same record? These cases often reveal more than the main flow, and they are only tested if someone writes them down.

Preparing test data

Test data makes or breaks UAT. Testing a billing system with three invented customers and round numbers tells you very little. Use data that looks like your real business: realistic customer names and addresses, real product codes, real GST rates, awkward cases such as a customer with two branches or an item sold in both metres and rolls.

Some practical points:

• Prepare data before testing starts, so testers are not inventing it on the day
• Include edge cases: zero quantities, very large orders, long names, Gujarati or Hindi text if your users will enter it
• Protect personal data: where possible use masked or made up records in place of real customer details, and limit who can see live data. India's Digital Personal Data Protection Act sets out duties for handling personal data, so check your approach with your lawyer
• Test in a separate environment, so test orders and invoices never mix with live records

Recording results

Record every test, whether it passed or failed. A shared spreadsheet works well for most projects. For each test case, note:

• The result: pass, fail, or blocked
• What actually happened, if it differed from the expected result
• A screenshot or short screen recording for any failure
• Who ran the test and when

Classify each failure so the delivery team knows what to fix first. A simple scale is enough:

• Blocking: the requirement is not met and the work cannot be accepted
• Major: the requirement is partly met, with a clear gap
• Minor: the requirement is met and something small needs correcting, such as a label or alignment

Keep the record factual. "The invoice total is INR 1,180 and should be INR 1,121 for this order" is far more useful than "billing is wrong".

Separating defects from new ideas

During UAT people will think of improvements. That is a good thing, and those ideas need their own list. A defect is a gap between the delivery and the specification. A new idea is a change to the specification. Mixing the two makes acceptance impossible to decide, because the target keeps moving. Record new ideas separately and plan them into a later block.

Accepting or sending back

When the tests are run, the UAT owner reviews the record and makes a recommendation.

Accepting

If every requirement in the specification passes, the delivery is accepted. Minor issues can be accepted with a note that they will be corrected, if both sides agree. Record the acceptance in writing, with the date and the version tested, so there is no doubt later about what was accepted.

Sending back

If any requirement fails, send the delivery back with the record. List each failed test, the expected result and what happened. The delivery team corrects the gaps and returns the work, and you rerun the failed tests along with a quick check of the areas around them, since a fix in one place can affect another.

How long each side has for testing and corrections is set out in your specification or agreement. Agree it before work starts so nobody is waiting on an unclear deadline.

How UAT ties to paying after acceptance

Under many contracts, payment depends on time passing or milestones being reached. Under pay after acceptance, payment depends on your acceptance, and acceptance depends on UAT. That makes UAT the most important control you have as a buyer.

At 2good, each block of work is built against a signed Statement of Work that defines done. The work is delivered in increments and reviewed along the way, with senior review, testing and project management included. You test the result against the Statement of Work. If it meets it, you accept and pay. If it does not, it is not accepted, and it is put right. There is no advance, so no money changes hands before you are satisfied.

This arrangement works best when the specification is clear and the UAT plan is written early. Draft both before the first block starts, and the acceptance step becomes a straightforward check. Read more about the offer, see the rates on the pricing page, or contact us to plan your first Statement of Work.