Acceptance testing and go-live for business software

The vendor says it is delivered. You have a few days to say yes or no, and a signature to put at the end of it. Most guides stop where the real risk starts: they describe the document to fill in, then leave you alone facing the cutover. This one follows the whole sequence, from delivery to the end of close monitoring, and says at each step what gets decided and what commits you.

✅ What is acceptance testing for business software?

Acceptance testing for business software is the phase in which the company that ordered the tool checks, before opening it to its teams, that what was delivered does what was asked. It is not about code quality: the vendor has already tested that on its side. It is about real usage, process by process. And it ends in a written decision that commits both parties.

The international testing body, ISTQB, does not describe one acceptance test but several. Its dedicated syllabus names user acceptance testing (UAT), contractual acceptance testing, regulatory acceptance testing, and alpha and beta testing. It mentions a sixth form, operational acceptance testing. The syllabus deliberately leaves it out of scope: it is “generally performed by teams that will operate the system rather than by testers and business analysts”.

The three you will actually meet

Practice has settled on a simpler split than the ISTQB taxonomy, and it is the one your vendor will use. It does not map exactly onto the international terms, but it has the merit of saying who does what.

An acceptance criterion is not a test case

Confusing the two is what produces unusable test plans. According to ISTQB, an acceptance criterion is a measurable statement “which can be either true or false” and which defines what has to be checked. It does not contain the procedure. Test cases are derived from it: they say how to check, step by step, with precise data.

In practice: “an invoice cannot be validated without a customer VAT number” is an acceptance criterion. “Open invoice INV-2026-014, clear the VAT field, click Validate, check that the button stays disabled and that a red message appears under the field” is a test case. The first comes out of your requirements work, the second is written when you prepare the acceptance campaign.

👥 Who tests, and when?

Functional acceptance belongs to the people who will use the tool daily, not to IT and not to the vendor. That principle is also what makes it hard to organise in a smaller company: the best testers are the ones whose time is already spoken for. So the calendar is set well before delivery. It is not discovered on the day the vendor announces it is ready.

When there is no dedicated project office

Writing on acceptance testing almost always assumes a two-headed organisation, business-side project ownership on one side and technical delivery on the other. In a company of twenty people, neither entity exists. Three roles are enough, and they can be held by people who already do something else.

1. One owner per critical process. Whoever knows invoicing best tests invoicing. They do not need to know how to write a test case: they need the list of situations to try, and the right to say it is not good enough.
2. A single decision-maker. Someone who settles it when an owner wants to block go-live over a detail, or when two departments ask for opposite things. Without that person, acceptance sinks into discussion.
3. One point of contact on the vendor side. A single place where defects are reported, in a single tool. Reports sent as private messages get lost, and nobody knows any more what has been fixed.

Waterfall acceptance, agile acceptance

In a waterfall project, acceptance is a block after development: the software is delivered complete, tested complete, accepted in one go. The advantage is contractual clarity. The drawback is concentrated risk: everything surfaces at the end, including trade-offs that should have been settled six weeks earlier.

In an agile project, validation happens along the way, each delivered increment being checked as it lands. Bad surprises are smaller and arrive sooner. That does not remove the final acceptance phase: end-to-end journeys, data migration and exchanges with your other tools still have to be checked, and nobody could test those increment by increment.

When lightweight acceptance is enough

Not every delivery deserves the full procedure, and pretending otherwise would waste your time. An internal tool used by three people, with no sensitive data, no integration and no regulatory obligation, is validated perfectly well in a hands-on session with a written summary. What triggers the full procedure is not the size of the budget: it is the presence of at least one of four things — personal data, money, a regulatory obligation, or a process that stops the business if it fails.

🧰 What to line up before you start

An acceptance phase that starts unprepared produces unusable feedback: “it’s buggy”, “that’s not what I pictured”, screenshots with no context. What follows is prepared before delivery, while the vendor is still building. Written down and put together, this set has a name: it is the acceptance test plan, the document that says what will be checked, by whom, on which data, and on what conditions the software will be accepted. Two lists, depending on who produces what.

What you gather internally

1. The list of critical processes to cover. Not every feature: the ones whose failure costs money or stops work. That list defines the scope under test, and what is explicitly out of it.
2. A realistic test data set. Varied enough to contain the awkward cases of your business: the customer with no VAT number, the zero-value order, the seven-year-old record. Those are what break software, not average cases.
3. Tester availability, blocked in calendars. Acceptance does not fit in the gaps of a busy week. Slots are booked in advance, with the agreement of each tester’s manager.
4. A named, reachable decision-maker. Including during holidays, if acceptance falls in the summer. A decision that waits three days costs three days.

There is an exception, and it is a narrow one. The regulator accepts that “tests run on fictitious or anonymised data are sometimes not sufficient”. Testing in pre-production with real data then becomes possible under two cumulative conditions: that the environment is “configured and secured to the same level as the production environment”, and that the service has “already passed all tests (unit, integration and functional) in the development and test environments”. In other words, copying the production database onto a tester’s laptop, a common habit, meets neither.

What the vendor must provide

1. An isolated acceptance environment, with its address and credentials. Separate from production, and separate from where developers work: otherwise your tests change under your feet while you run them.
2. Test accounts matching your real roles. An administrator, a standard user, a restricted profile. Testing only as an administrator proves nothing about what the team will see.
3. The rollback procedure, written and already tested. Not the promise that a rollback is possible: a description of what happens, how long it takes, and what is lost along the way.
4. A single channel for reporting defects, with a reporting template: what I was doing, what I expected, what happened, a screenshot.

🛠️ From acceptance testing to go-live: the procedure

The full sequence is eight steps that follow one another without overlapping. The first five are acceptance testing proper, the sixth records the decision, the last two cover go-live. Most guides stop at the sixth. It is precisely between the signature and the moment users are let in that projects come apart.

The timeline, from above

Steps 1 to 3: prepare the campaign

1. Freeze the scope under test. Write what will be checked and, just as important, what will not. An unwritten scope expands. A tester tries an unrelated feature, finds a minor defect, and blocks the launch over a screen nobody will use for six months.

2. Write the test cases. A test case is judged on one criterion: someone who was not part of the project must be able to replay it identically without interpreting anything. That means three things: precisely named data, one feature per case, and an expected result stated in checkable terms: “a confirmation message appears at the top of the screen”, not “it works”.

3. Prepare the data sets and the access. Load the test data into the acceptance environment, check that every tester can log in with the right profile, and confirm the environment will not be changed during the campaign.

Steps 4 and 5: run, grade, arbitrate

4. Execute the cases and record. Every case comes out with an unambiguous status: pass, fail, not tested. A “half-passed” case does not exist. Defects go through the single channel, with the same reporting template for everyone.

5. Grade every defect, then arbitrate. Three levels are enough, and it is the business consequence that decides, not how hard the fix is.

• Blocking : the process cannot be completed, or a value is wrong. No go-live
• Major : the process works, but through a painful workaround. Go live if the workaround is documented and the fix is dated
• Minor : cosmetic or comfort issue. Go live, fix later

The hardest call is elsewhere. It is the line between a defect, where the software does not do what the scope said, and an enhancement, where it does exactly what was planned but real use shows something else is needed. The second is legitimate and frequent. It is not handled inside acceptance: it is quoted separately. That call becomes easy when the scope was written down in advance.

Step 6: the acceptance report, and what signing triggers

6. Record the decision in writing. The acceptance report is not paperwork: it is the document that shifts responsibility. It records what was tested, the results, any reservations, and the decision.

The most thoroughly documented framework in France is the one governing public contracts. The general terms for public IT contracts organise the sequence into distinct steps: verification operations, quantitative then qualitative verification, decision after verification, then acceptance, with the buyer also able to defer, apply a price reduction or reject. And above all, the acceptance decision “constitutes acknowledgment of service rendered and marks the starting point of the warranty periods”.

Keep that mechanism in mind even if your contract is a private one: the signature does not only say “I am happy”, it starts clocks. In a private contract, exactly what it starts, balance due, warranty duration, move to maintenance, depends entirely on what your contract says. That is the moment to read it, not afterwards.

Steps 7 and 8: the cutover, then close monitoring

7. Decide, switch, check immediately. Go-live is prepared like a timed operation: who does what, in what order, at what time. Three things are worth settling while everyone is calm, before the day itself.

• The go decision, taken collectively. Each owner says yes or no, explicitly. Silence is not a yes
• The cut-off time beyond which you no longer switch. Past that point, if everything is not in place, you call it off and try another day. That time is set the day before, never in the heat of the moment
• The immediate check after switching. A short list of verifications on vital processes, run within minutes of opening: log in, create a record, save it, find it again

If the tool replaces an existing system, the data migration is the riskiest part of the day, and it is rehearsed before the real one. That subject has rules of its own, covered in our complete guide to custom software development.

8. Monitor closely, then exit monitoring. The first days call for reinforced support and a regular read of the technical logs. This period, often called hypercare, ends on conditions agreed in advance: no blocking defect left open, activity back to normal volume, team autonomous on everyday processes. Never on an arbitrary date. At OTTOPILOTE it is covered by the 30 days of corrections included after delivery, stated on the pricing page; beyond that, monthly support is optional and quoted, and you remain the owner of the project, the credentials and the documentation.

💶 What acceptance testing really costs you

Acceptance has a cost, and it appears on no quote: it is time taken from your teams. No public source quantifies it. The ranges in circulation, a percentage of development time, a number of weeks per project type, all come from agency or vendor blogs with no named study behind them. Rather than repeat an unverifiable figure, here is how to work out your own.

Working out your effort, item by item

The calculation starts from three numbers you already know: how many critical processes are in scope, how many test cases per process, and how many testers are involved.

What makes the bill explode

Two mechanisms, and only one is avoidable. The first: acceptance pushed to the end of the project, prepared at delivery instead of during development. Test cases then get written in a rush, badly, and campaigns multiply. The second: rejection discovered after go-live, when the team refuses the tool because nobody had it tested by the people who would use it. The cost is no longer that of acceptance, but that of redoing part of the project.

⚖️ What acceptance testing can and cannot do

Well run, acceptance genuinely protects you, but not from everything. Knowing where it stops avoids two symmetrical mistakes: treating it as paperwork, or expecting it to repair what went wrong upstream.

🚧 The most common pitfalls

Six situations come back project after project. None is a technical inevitability: all are prevented by a decision taken upstream.

🎯 In short

To frame a business software project end to end, acceptance and go-live included, describe your need in a few sentences: the quote arrives within 24 working hours, and scoping is week 1 of the project.

📚 Sources

• ISTQB, Certified Tester Foundation Level Specialist Syllabus — Acceptance Testing, version 1.0 of 21 June 2019: forms of acceptance testing and the definition of acceptance criteria
• Légifrance, order of 30 March 2021 approving the general terms for French public contracts in information and communication technologies: verification sequence, acceptance, and the starting point of the warranty
• CNIL, Personal Data Security Guide, sheet “Encadrer les développements informatiques”, updated 14 March 2024: test data and the conditions for using pre-production (in French)
• CNIL, “L’anonymisation de données personnelles”: families of anonymisation techniques (in French)
• OTTOPILOTE pricing page: 30 days of corrections included after delivery, ownership of code and credentials, optional monthly support (in French)