What Belongs in the Acceptance Test So Silent Failures Show Up

Most acceptance tests for an automation consist of running a few transactions and looking at a log with no red lines in it. That is the weakest possible evidence. A successful run only means that no system involved objected. It does not mean the data arrived complete at the other end.

The clearest illustration is field length. Every text field in every target system has an upper limit, and in ERP and CRM systems 255 characters is the classic one. What matters is not the number but the behaviour when you exceed it.

Some systems reject, others truncate

A system that rejects text which is too long is the pleasant case. The interface returns an error, the run stops, somebody notices. You lose a record and you know about it.

Another system takes what fits and discards the rest. No error, no warning, a success response. As far as the automation is concerned the transaction is done, the log shows a green line, and the target system holds a text that ends in the middle of a word.

On top of that, the target system's own screen shows the truncated value with no marker at all. To the person in the office that is the complete content of the field. When the customer calls and reads out what they wrote, it sounds like a misunderstanding on the phone rather than an interface problem.

Below the limit sits a second quantity that is rarely documented: the unit being counted. A word with an accented character has fewer characters than bytes, because such characters occupy two. A field limited by bytes therefore truncates German or French text earlier than expected, and it does so precisely on names and place names.

The damage depends on which field gets cut

A truncated delivery note costs a phone call from the driver. Annoying, but contained.

It gets expensive in fields that something else depends on later. A reference number missing two digits blocks the automatic matching of an incoming payment. A truncated payment reference turns a receipt into a manual case. A shortened customer purchase order number leaves your invoice sitting in their accounts payable queue until somebody chases it.

That gives you the actual rule for acceptance. Not every field deserves the same scrutiny. But every field that a later match depends on has to be checked, and checked in the target system rather than in the automation's own log.

Why these errors never appear during testing

Testing runs on sample data, and sample data is short. Nobody keying in a test order writes three sentences about the gate, the contact person and a mobile number into the comment field. Real customers do exactly that.

So the most important rule for acceptance is that it uses real transactions, and deliberately the most awkward ones. The longest comment of the last few months. The customer with the longest legal name. The order with the strangest reference. Those transactions already exist in your system. Somebody just has to pull them out.

Three checks you can demand without technical knowledge

The first is the comparison at the destination. Take five processed transactions and compare field by field what the source held and what the target now holds. Not a quick skim, a side by side comparison.

The second is the edge case. Have one transaction run through with deliberately oversized text and ask to be shown what happens. There are three acceptable answers. The transaction is rejected and reported. The text is shortened, but the shortening is made visible and reported. Or the long text is moved into a field designed to hold it. Nothing happening is not an acceptable answer.

The third concerns the notification itself. Ask where such a warning goes. An entry in the platform log is not a notification, because after go live nobody opens it. A notification goes to a person, or to a mailbox that somebody owns.

This is a question of price, not of diligence

Checks like these do not appear on their own. They are additional work, and they belong in the request for proposals. Otherwise one supplier prices the normal case and another prices the normal case plus safeguards. The cheaper offer wins and becomes the more expensive project.

State in your enquiry what the worst conceivable error in this process would be. An internal note may occasionally lose a sentence. Anything touching invoices, orders or patient data may not, and that difference decides how much checking gets built around the business logic.

Sophera Consulting records before the build which fields are critical, how the workflow must behave at the limit and who receives a notification, then quotes a fixed price on that basis, with no subscription. The entry point is the free Automation Check.

The recommendation

Agree the acceptance test before the build, not after it. Two sentences are enough. Testing happens in the target system using ten real transactions, including the longest and the strangest of recent months. And for every field a later match depends on, the supplier demonstrates what happens when the limit is exceeded and who finds out about it.

An automation that reports a problem is worth more than one that is always green. The second kind only works flawlessly for as long as nobody looks.