The new software is built, and the developer says it is finished. Before you believe it, the people who will work with it should try it out - with real examples from their own business, in a place where nothing can go wrong. That place is called a test environment; the trying out is called acceptance.

Both sound like formalities. In practice, acceptance is the moment that shows whether the software matches the workflow and whether the concept was understood correctly. Skip it, and you move that discovery into live operation - where every mistake hits a customer, an invoice or a delivery note.

What a test environment is

A test environment is a second, complete copy of the software, separate from live operation: its own database, its own address, its own logins. What happens there has no consequences. No customer receives an invoice, no delivery note goes out, no stock level changes. You may break things, delete them and create the same order three times.

Without this separation, every trial becomes a risk. Then people test cautiously, which means too little - or with orders that someone later has to delete from the live system, catching the wrong one as they do.

The test environment stays in place after launch. Every later change goes there first, as described in Software after launch.

Who tests

Not the developer, and not only the managing director. The testers are the staff who will work with the software: the colleague in sales who creates orders, the warehouse worker who books goods receipts, the fitter who records his report on his phone. They know the exceptions that appear in no concept: the customer with two delivery addresses, the item sold by the metre rather than by the piece, the invoice a third party pays.

The developer is present, but does not demonstrate - he watches. Wherever an employee hesitates, there is something to learn, even if the software is working correctly.

Test data: real examples, not invented ones

Nobody finds anything with “Test customer 1” and “Item A”. Testing is done with real examples: the last difficult order, the complaint everyone is still annoyed about, the customer with the special terms. Ideally the master data comes from the live system into the test environment - customers, items, prices - and the transactions are re-enacted.

Personal data in a test environment needs checking. Talk to your data protection officer about whether it may be copied unchanged or has to be anonymised. If old data is to be migrated, the test environment is also the place where the migration is rehearsed first.

How acceptance works in practice

  1. Choose the examples. Before the session, collect the transactions the software is meant to handle: some typical, some difficult. The template is the detailed concept: every function described there gets at least one example.
  2. Play them through. Staff work through the examples in the test environment, from start to finish: create the order, print the delivery note, generate the invoice, hand it over to accounts. Not function by function, but transaction by transaction.
  3. Write down the deviations. Everything that differs from what was expected goes on a list: what was done, what came out, what should have come out. Small things too - the field in the wrong place, the sort order, the label.
  4. Sort. Together, the list is divided into three groups: what blocks the launch (a wrong invoice, a missing workflow), what should still be fixed before launch, and what comes later. Not every deviation is a defect. Some are new wishes that only arose while trying things out - those belong on the list for later, not in the acceptance.
  5. Fix and re-check. Fixed items are played through again in the test environment, by the same staff. Then what is on the list is accepted - in writing, so both sides know what stands.

Training as a side effect

Anyone who took part in the acceptance hardly needs training any more. They have operated the software with their own transactions, have seen where it works differently from the old one, and know whom to ask. The colleagues who were not there learn from those who were - that works better than any presentation. Acceptance is therefore not extra work alongside the rollout. It is part of it.

Moving into live operation

After acceptance, the checked version is moved into live operation. That includes: migrating the real data or deleting the test data, creating logins, checking permissions, switching interfaces to ERP or accounts over to the live systems, setting up backups and restoring one once. Decide from when the old solution is no longer used, and who is available for questions in the early period - ideally the staff who did the testing.

How to tell the acceptance was too short

  • Shortly after launch, fields are missing that “everyone would have needed anyway”.
  • Invoices have to be corrected in live operation.
  • Staff carry on working with the old list “until the new one works”.
  • There is no list of deviations, only the memory of a conversation.
  • Only the managing director saw the software before launch.

Questions before acceptance

  • Is there a test environment separate from live operation?
  • Which staff will test, and have they been given the time for it?
  • Which real transactions will be played through, and are they on a list?
  • Who keeps the list of deviations, and who decides what blocks the launch?
  • Is it settled how test data may be copied over?
  • How does the accepted version get into live operation, and when is the old solution switched off?

With us the test environment exists from the start, and acceptance runs with your staff and your examples - not ours.