How to Test a System Before You Trust It

Something has been built and it appears to work. The question nobody asks well is how you find out whether it is right before it is doing real work on real clients.

Most businesses answer this by trying it a few times, agreeing it looks good, and switching it on. That is not a test, it is a demonstration, and demonstrations only ever surface the cases somebody thought to try.

Run it in parallel first

The single most useful method costs nothing: for two weeks, run the new system alongside the existing one and let it act on nothing.

Every real case goes through both. The person handles it as they always have. The system produces its answer in the background and that answer is recorded rather than used. At the end you have a few hundred paired judgements from genuine work, not from test cases.

Then you compare. Not on averages, on disagreements.

The disagreements are the entire test

Where the two agree, you learn nothing. Where they differ, one of three things is true, and each has a different response.

The system was wrong, which tells you what to fix. The person was wrong, which happens more often than anybody expects and is frequently the moment the project justifies itself. Or the case was genuinely ambiguous, which means it should never have been automated and needs a route to a human.

That third category is the one people miss. A system that confidently handles ambiguous cases is worse than one that refuses them, because refusals are visible and confident errors are not.

Decide the pass mark before you look

Write down what accuracy is acceptable, and write it down before any results exist. Otherwise the number becomes whatever you got, which is how everything passes.

The right threshold depends entirely on the cost of being wrong, and that cost is rarely symmetrical. On lead routing, sending an enquiry to the wrong salesperson costs a day. On an invoice, a wrong figure costs a client relationship. On a compliance check, a false pass is a legal exposure and a false fail is five minutes of somebody’s time.

So set two thresholds, not one, and be strict about the expensive direction. A system permitted to say “I am not confident, look at this” can be held to a much higher standard on the answers it does give.

Test the failures, not the successes

Everybody tests whether a system does the right thing with good input. Almost nobody tests what happens with bad input, and that is where live systems break.

Send it the malformed cases deliberately. The blank field. The document that is upside down. The name with an apostrophe. The date written in the other country’s format. The duplicate submitted twice in four seconds. The attachment that is a photograph of a screen.

Then break the connections. Take the other system offline mid run and see what happens. Does it retry, does it queue, does it lose the record, does it tell anybody? A system that handles perfect input beautifully and drops work silently when an integration times out will cost you more than it saves.

The confidence question, and why AI changes the answer

Traditional software either matched a rule or it did not, so testing meant checking rules. AI based steps are different in one specific way: they produce a judgement and they can tell you how sure they are about it.

That is more useful than it first sounds. It means you can set a threshold and route everything below it to a person automatically, so the system handles the eighty percent it is confident about and escalates the rest with a reason attached. You get the volume without the exposure.

It also means the parallel run gives you the data to set that threshold properly rather than guessing. Look at where the errors actually clustered on the confidence scale, and put the line there.

Any system we build is designed to be tested this way, because a step that cannot say when it is unsure has no business making a decision unsupervised.

Who signs it off

The person who does the work today, and nobody else.

Not the person who commissioned it, who wants it to work, and not the person who built it, who knows which cases it handles. The operator is the only one who will look at a disagreement and say that the system was right and everyone in the business has been doing it wrong for years, or that the answer is technically correct and would start an argument with a client.

Give them the disagreements, not a summary. A success rate invites agreement; a list of specific cases invites the objection you actually need to hear.

Then release it narrowly

Do not switch it on for everything at once. One region, one client type, one branch, one salesperson.

Keep the old route available for two weeks and watch what people do. If they quietly go around the new system, that is the most important test result you will get and it will not appear in any accuracy number. It usually means the system is right and something about it is unusable, which is a fixable problem and an invisible one if nobody is watching.

The checklist

• Two weeks in parallel on real cases, acting on nothing.

• Review the disagreements, all of them, with the person who does the work.

• Pass marks written before results, and different marks for the two error directions.

• Deliberate bad input and at least one severed connection.

• A confidence threshold below which it escalates rather than guesses.

• Narrow release, old route open, somebody watching whether people use it.

Two weeks of this is the difference between a system the business trusts and one that gets quietly abandoned after the first bad week.

AI Optimize runs the parallel period as part of every build, and shows you the disagreements rather than a success rate. That work sits under Custom AI Integrations.