Who should carry out user acceptance testing (UAT)?

It should be done by the colleagues who will actually use the system day to day, not delegated to whoever in the office is best with computers. Only the real administrators, support staff, and salespeople will notice where a workflow does not match how the work is done. It also helps to appoint a single acceptance coordinator who gathers all the feedback and passes it to the development team in one channel; several people messaging engineers directly is the most common cause of acceptance dragging on and scope slipping. The vendor, for its part, should complete its own internal testing before handover rather than leaving obvious faults for the client to discover as the first user.

Which problems found during acceptance should the vendor fix, and which should be quoted separately?

The dividing line is whether what was built differs from what was agreed, or whether what was agreed now needs to change. The first is a defect and sits with the vendor to correct. The second is a new requirement and should be estimated separately for effort and schedule. That is why acceptance goes smoothly or badly depending on how specific the original requirements document and acceptance criteria were. If the requirement says only that something should be easy to use, neither side has any basis for a judgment, so it is worth writing this boundary and the change process into the contract before the project starts.

What does the warranty period after acceptance usually cover?

A warranty covers defects that fall short of the agreed acceptance criteria. It does not cover new functionality, and it does not cover problems caused by your own changes to the code or by a third-party service releasing an update. The contract should be explicit about three things: what is covered, how response and repair differ by severity, and whether the arrangement converts into a maintenance contract or moves to per-request billing once the warranty ends. Where external systems are integrated, agree before the integration work begins whether breakage caused by the other side updating its service counts as warranty work.

Software Acceptance Testing: UAT and Defect Tiers

The sentence most likely to start an argument at the end of a project is the one that asks whether the work counts as finished.

The vendor says every feature has been built; the client says the thing does not work the way it is supposed to. The problem is usually not that anyone cut corners. It is that neither side ever agreed on a shared definition of “done.” Acceptance goes well or badly not because of how the final two weeks of testing are run, but because of whether the standard was written down at the start.

Acceptance criteria are not invented at acceptance; they grow out of requirements

Acceptance criteria — plainly, the statements that define what counts as correct — should take shape during the requirements phase. The method is simple: rewrite every functional description in the requirements document as a sentence that can be judged true or false.

Requirement: “Members can edit their own profile.” Acceptance criterion: “After logging in and opening the member area, the user can change name and mobile number, save, log out and log back in, and see the new values.”
Requirement: “The admin system can export orders.” Acceptance criterion: “After selecting a date range and exporting, the file opens in a spreadsheet application and contains order number, amount, status, and creation time.”

The difference is that the first cannot be judged and the second can. If your requirements document is still written in the first style, fix that first — How to Write Software Requirements covers how.

Three further categories of criteria are routinely omitted, and they are where most disputes end up:

Non-functional criteria. Page load speed, number of concurrent users, and the range of browsers and phone models to be supported. If these are not written into acceptance, complaining after launch that the system feels slow has nothing to stand on; for how to measure properly, see the website speed optimization guide.

Data criteria. Whether legacy data is being migrated, which of it, and how record counts and content will be verified once it has moved.

Permission criteria. What each role can see and what each role must not be able to do. Permissions are the single area most often found to be wrong only at the acceptance stage.

How to write test cases, for people who are not engineers

A test case is a checklist you follow step by step and then compare against an expected answer. Every row needs at least four columns:

Column	Contents
Scenario	Which role, and in what state, is performing the action
Steps	The specific sequence of clicks and inputs
Expected result	What should appear
Actual result	Filled in by the tester; anything that does not match is logged as a defect

Beyond the happy path where everything goes correctly, three more categories are essential:

Invalid input. Blank fields, excessively long strings, special characters, and badly formatted phone numbers or company tax IDs.

Boundary conditions. Quantity set to the maximum, stock at exactly zero, a promotion expiring at that precise moment, the last available place being filled.

Permission violations. Take a low-privilege account and type the URL of a high-privilege page directly, then see whether the system blocks it.

In practice, the happy path nearly always passes. The problems are found by the three categories above.

Who tests: three roles, none of them optional

The vendor’s internal testing. This should happen as soon as a feature is complete. Obvious faults should not be left for the client to discover as the first user.

User acceptance testing on the client side. Performed by the colleagues who will actually use the system. Only real administrators, support staff, and salespeople will surface the places where a workflow does not fit the job.

Bystander testing. Find a colleague with no involvement in the project, give them no instructions, and see whether they can complete the main task unaided. This is the cheapest and most honest usability check available.

Appoint one acceptance coordinator to collect all feedback and report it in a single channel. Several people messaging engineers separately is the most common reason acceptance drags on.

Defect severity: not every problem should block launch

Throwing every piece of feedback into one pile labeled “still not right” only exhausts both sides. In practice, four levels are the minimum:

Blocking. A core flow cannot be completed — orders cannot be placed, users cannot log in, data does not save. Must be fixed before launch.
Serious. The feature works but produces the wrong result — a total that does not add up, a notification sent to the wrong recipient. Must be fixed before launch.
Standard. Awkward interactions or inconsistent display that do not affect the outcome. Can be scheduled into the warranty period.
Minor. Typos, uneven spacing. Collect them and fix in one pass.

Also separate defects from new requirements. A defect is where what was built differs from what was agreed; a new requirement is where what was agreed now needs to change. The latter is a change request and should be estimated separately for effort and schedule rather than absorbed into acceptance for free. When that line is not drawn in the contract, acceptance turns into a tug of war; for the relevant clauses, see How to Choose a Software Development Company.

How acceptance and payment milestones fit together

The point of payment milestones is to give both sides a reason to do each stage properly. A common structure splits payment across confirmation of requirements and design, the mid-point of development, successful acceptance, and the end of the warranty period, with a defined deliverable attached to each.

A few principles are worth holding to:

Every milestone needs a verifiable deliverable, not a statement that progress is roughly on track
Acceptance needs a defined response window, and the contract should say what happens if the client misses it
The final payment should not all be held back until the very last moment, nor should it be settled before acceptance

NETVANA works in two-week sprints, with an operable demo at the end of each cycle, precisely so that problems surface during the project instead of accumulating into one confrontation at the end; for the full breakdown of phases, see the software development process.

Launch is not the finish line: what the warranty covers

Acceptance is usually followed by a warranty period. The contract should be explicit about three things:

Scope. A warranty covers defects that fall short of the agreed acceptance criteria. It does not cover new functionality, and it does not cover problems caused by your own modifications or by changes to a third-party service.

Response and repair by severity. A blocking problem should not be handled on the same terms as a cosmetic one.

What happens when the warranty ends. Either it converts into a maintenance contract or it moves to per-request billing. For the common models and the disputes they generate, see What Website Maintenance Actually Covers.

If the system integrates with external services, confirm one more thing specifically: whether breakage caused by the other party updating their system falls inside the warranty. Agree that boundary before integration work begins; for background, see the guide to system integration and API development.

Settle these points before acceptance starts

Acceptance often drags not because there are too many problems, but because testing began before anyone was ready. Confirming the following in advance saves a great deal of back and forth:

Whether the test environment is separate. Acceptance should take place in an environment configured identically to production but holding data you are free to break. Testing directly in production produces test orders and test text messages sent to real customers.

Whether test data is in place. To verify membership tiers you need test accounts at every tier; to verify the order flow you need working test payment credentials. Without these prepared in advance, testing stalls at the first step.

How long testing will run, and who is available. Acceptance requires real users to spend real time. If everyone’s schedule is already full, acceptance degenerates into opening the system, glancing at it, and declaring it fine — which leaves every problem to surface after launch. Put the time in the calendar in advance.

A single reporting channel. Use one document or one tracking tool, with an ID, a status, and an owner for every issue. Feedback scattered across different chat windows will always lose something.

An agreed definition of passing. Does acceptance pass once all blocking and serious defects are cleared, or does it require zero defects of any kind? The latter does not exist in practice, and insisting on it only guarantees the project never closes.

The three most common acceptance disputes, and how to avoid them

“This is not what I pictured.” Usually the result of moving through design sign-off too quickly. Avoid it by confirming flows with a clickable prototype before development starts, rather than seeing the result for the first time when it is built.

“We definitely discussed this feature.” Verbal discussion with no record becomes one account against another. Every conclusion should be written back into the requirements document or the meeting notes and confirmed by both sides.

“Performance is not what we expected.” “Slow” is not an acceptable criterion. Agree the measurement conditions and tools during the requirements phase: which network conditions, which pages, and which tool will be used to read the result.

These three have something in common. None of them is created at the acceptance stage; all of them are left there by an earlier one. That is also why, when evaluating a vendor, the questions worth asking go beyond the quote to how they handle requirements sign-off and change requests.

How well acceptance goes is largely decided in the first week of the project. Requirements written so they can be judged true or false, criteria both sides have agreed, and defect severity defined in advance turn the final stretch into a confirmation rather than a contest.

If your project is about to enter acceptance, or you want the acceptance clauses settled before work starts, talk to NETVANA about your project — we clarify scope and delivery standards before discussing anything else.

Further reading: for turning requirements into a form that can actually be accepted, see How to Write Software Requirements; for why projects tend to slip, see Why Software Projects Run Late; and for how to discuss accumulated quality problems after launch, see Technical Debt Explained for Business Owners. For scoping the first version you will have to sign off, see A Guide to MVP Development; and for the store submission steps that follow acceptance, see The Complete App Store Launch Checklist. For what the test types your vendor mentions actually cover, see What Automated Testing Is, in Plain English. The same severity thinking from UAT carries into how you report bugs to your vendor; see How to Report Bugs to Your Vendor. For the test environment where acceptance testing happens, see Test, Staging, and Production Environments.