Your vendor says it is done: how to run acceptance testing before you sign off

When software is delivered, the decision in front of you is not "does it work" but "does it meet the criteria we wrote down", and that answer has to exist on paper. Three separate pieces of work produce it. Acceptance testing, where real users do their own jobs end to end, with migrated data and their own permissions. Operational acceptance, where whoever will keep the system running watches a restore from backup, checks the alerts and walks through a rollback. And a go-live plan. Sign before those three are finished and every problem that surfaces afterwards lands on your side of the table. Turkish contract law is blunt about it: a client who neglects to inspect the work and report defects is deemed to have accepted it.

A demo is not an acceptance test

In a demo the vendor picks the route. They prepare the data, they set up the scenario, and when something looks odd they say "that will behave differently in production" and keep moving. In acceptance testing you pick the route. The data is the data that was actually migrated, the user signs in with their own account, works under their own role and does their own job.

Microsoft's Dynamics 365 implementation guidance names the two things teams skip most often. Do not hand everyone the system administrator role during testing, assign people the security roles they will really have. And run the test in an environment that approximates production as closely as possible. A test run on an empty database with admin rights is not a rehearsal of anything you will face on launch day.

Exit criteria are written before delivery, not during it

If you start writing acceptance criteria in delivery week, you are not testing, you are negotiating. Criteria belong in an annex to the contract, next to the requirements, and they need numbers in them. "Should load fast" is not a criterion. "The order list opens in under two seconds with 50,000 records" is. We covered how to write requirements that can be measured in writing software requirements.

For the non-functional half there is a ready-made agenda. ISO/IEC 25010 was revised in 2023 and its product quality model now has nine characteristics: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility and safety. Usability and portability from the 2011 edition were replaced by interaction capability and flexibility, and safety was added. Walk the list in your acceptance meeting and do one of two things with each item: write a criterion, or record that it is out of scope for this project. Characteristics nobody mentions are the ones that turn into arguments later.

There are four kinds of acceptance testing, not one

In ISTQB terms, acceptance testing comes in four common forms: user acceptance testing, operational acceptance testing, contractual and regulatory acceptance testing, and alpha and beta testing. The second one is almost always the one that gets dropped.

Operational acceptance asks whether the software is ready for the business to run, not whether it is ready for a user to click. Has a restore from backup actually been performed, and how long did it take? Is monitoring in place, and whose phone does the alert reach? Is the rollback procedure written down, and has anyone executed it once? When something breaks, where are the logs and how long are they kept? Asking these questions for the first time in production is an expensive way to find the answers. Observability, SLOs and error budgets covers how to put numbers on that side.

A short security pass before the signature

Acceptance is also the last checkpoint for security. Start with five questions. Are there API keys or passwords left in the repository? Have the default administrator accounts been disabled? Is the role matrix actually enforced? Have the dependencies been scanned for known vulnerabilities? Do the actions that move money or change permissions land in an audit trail?

Do not leave the permission checks to a separate scanning exercise. Put them straight into the acceptance scripts. "Can sales rep A open sales rep B's customer record" is something a user can test in ten seconds, and most leaky authorization shows up under exactly that kind of poking. For the detail, see authorization models, secrets management and audit log design.

Write the scripts in business language

A weak acceptance script reads like this: "Open the Orders screen, click New, fill in the fields, press Save." The tester has no idea what they are supposed to verify, so they click through and pass it. A good script describes the job: "Cancel an order that is on hold, issue the credit note, confirm that stock went back and that the accounting entry was created."

Give every script one behaviour to verify, one owner and a written expected result. Your users have limited time, so pick the 20 to 30 scenarios that carry the most money and the most reputational risk, and rank them. Test with migrated data, and treat the migration itself as its own rehearsal, which we walked through in moving data from a legacy system.

A defect list that produces no decisions is just a document

Coming out of acceptance testing with 300 findings is normal. The problem is an unsorted list. Three buckets are enough: blocking (the work cannot be done, sign-off stops), significant (a workaround exists, it gets an owner and a date), minor (it joins the backlog). Severity and priority are different axes. A bug that loses data on a rarely used screen is severe but can wait; a misaligned button on the main screen is trivial but every customer sees it, so it may go first.

The acceptance record should carry three lists: closed, to be closed before sign-off with an owner and a date against each item, and deliberately deferred. For every entry in the third list, write down who approved the deferral. That single line ends the "who agreed to this" conversation six months later.

Conditional acceptance beats refusing to accept

Acceptance is not a binary switch. If what remains is small and the system can carry real work, conditional acceptance protects you without blocking the project: you accept, the open items are attached as a list, and part of the payment is tied to closing that list. Define the warranty period in the same text, along with which categories of defect get fixed at no charge during it.

How warranty and maintenance get billed depends on the contract model, and we compared how the two models distribute risk in fixed price or time and materials.

Inspection is a duty, not a right

Under Turkish law a software development engagement is usually treated as a work contract, and the Code of Obligations puts an active duty on the client. Article 474 requires the client to inspect the work after delivery, as soon as the ordinary course of business allows, and to notify the contractor of any defects within a reasonable time.

Article 477 ties off the consequence. Once the work has been accepted, expressly or implicitly, the contractor is released from liability, and a client who neglects to inspect and notify is deemed to have accepted the work. If a defect appears later and you do not report it without delay, you are again deemed to have accepted. Defects the contractor concealed intentionally, and those that a proper inspection could not have revealed, fall outside the rule. Article 478 sets the clock: for works other than immovable structures, claims arising from defects lapse two years after delivery, or twenty years if the contractor is grossly at fault. The practical reading is simple. Acceptance testing is not a courtesy, it is the step that keeps your remedies alive, and it needs a dated, signed record. If you sell to or buy from the public sector, the process is already regulated: an inspection and acceptance commission formed under Article 11 of Law No. 4735 takes delivery of the work.

Nobody goes live without a rehearsal

After the signature, the tightest window in the schedule is what is left. Microsoft's go-live checklist asks for a specific set of things first: scope agreed with stakeholders, every test cycle closed against its exit criteria and signed off, the cutover scripts tested and approved in advance, external dependencies aligned with the timeline, the production environment prepared and a support plan in place. Rehearsing the data migration several times, and measuring that it fits inside the cutover window, is on the same list.

Write the cutover plan hour by hour: which step, who performs it, how long it takes, who verifies it. Name one person who makes the go/no-go call, and define the rollback trigger before the day starts. "We will roll back if it goes badly" is not a plan. "If orders are not flowing within two hours, we return to the old system" is one. The techniques that shrink the outage itself are in zero-downtime deployments.

The first two weeks are a separate job

The period of intensive support right after launch is what the industry calls hypercare, and it is a line item you plan rather than improvise: who is watching, through which channel, at what hours, for how long, and at what threshold the team assembles. It also tends to expose what acceptance testing missed, because real user counts and real load arrive there first.

The handover list gets completed in the same weeks:

• The repository with its full history, plus build and deployment instructions verified on a clean machine.
• Where environment variables and secrets live, and who has access to them.
• Cloud, domain, certificate, email and payment provider accounts opened in the company's name.
• A runbook: restoring from backup, releasing a version, the common failures and the first response to each.
• The acceptance scripts themselves and any automated tests. They are the safety net for the next release too, which is the argument in test automation strategy.
• The open defect list, known limitations, and an inventory of dependencies and their licences.

Legal transfer of rights is a separate topic, and holding the code is not the same as holding the rights. Source code ownership and escrow covers that side.

One thing you can do this week

Find the clause in your contract where the word "acceptance" appears and answer three questions. Where are the acceptance criteria written down? Who signs the acceptance? For how long after signature, and for which categories of defect, does the warranty apply? If any of the three is blank, fill it in before the delivery date. Opened in delivery week that conversation becomes a negotiation; opened earlier it is just procedure.

If you want an independent party to run the acceptance review, that is work we do remotely at Wedevit: writing the criteria, preparing the scripts, triaging the findings and running the go-live checklist. What you are left with is a record you can sign and a decision you can defend.