Testing Business Software: The Checks to Run Before Daily Use

Testing a business system almost always fails the same way: the future users are called in, told "try it out," and they try the things they already know how to do. The software passes. Then, on the first day of real work, an order comes in that needs to be canceled after shipping, and no one had tested that.

Testing means writing down beforehand what should happen, then verifying that it does. The whole difference between the two comes down to the word "beforehand."

A Test Scenario Isn't "Trying Out the Program"

A scenario has four parts, and if even one is missing, the test is neither repeatable nor arguable.

• Starting data: which customer, which order, which warehouse, with what values.
• The role: who carries it out and with what permissions.
• The steps: what is done, in the order it's done.
• The expected result: what must be true at the end, written down before running the test.

The expected result is the part that gets skipped, and it's the only one that matters. Without it, the test ends with "it seems to work," which isn't an outcome but an impression, and it can neither be challenged nor confirmed.

A Test Plan: The Job Order

Illustrative example for a module that manages job orders. The tests are chosen to cover the three types you always need: the normal case, the exception, and what must be prevented.

The last three rows are the ones that always get forgotten. A system is also judged by what it refuses, and the refusal needs to be understandable: an operation blocked without explanation generates the same phone calls as an actual error.

The Tests No One Thinks to Run

• Unauthorized operations, actually tested with a restricted user and not just read off the permissions table. Printouts and exports need checking too, since confidential data leaks out through them more often than through the screens.
• Messy data: names with apostrophes, extremely long addresses, zero amounts, large attachments, duplicate rows.
• Interruptions: the connection dropping mid-save, two people editing the same record, the same operation submitted twice.
• Integrations when the other system doesn't respond: what the user sees, what stays pending, what happens once the other system becomes available again.
• Closing periods, if the software treats them differently.

Classifying Defects Instead of Just Listing Them

A list of sixty unclassified reports brings the project to a halt: no one knows where to start, and every meeting turns into a negotiation. Four categories, agreed on before you start, are enough.

• Blocking: prevents work and there's no alternative way around it. Must be fixed before launch.
• Serious: work is possible, but with a long workaround or a risk of error. Must be fixed before launch or right after, with a date.
• Minor: annoyance, formatting, unclear text. These are collected and fixed as a batch.
• New request: not a defect, but a feature that wasn't planned for. It needs to be recognized as such and evaluated separately.

The distinction between the last category and the others is what saves the project. Confusing a missing feature with a defect shifts the cost onto the developer and the deadline onto everyone, and turns testing into a never-ending job site.

Verifying Fixes Without Breaking Everything Else

Every fix needs to be verified by whoever reported it, not by whoever resolved it, by re-running the original test and not a similar one. Alongside it, a small set of tests on the main paths needs to be repeated: fixes carry side effects with them, and that's normal.

It's worth setting a limited number of deliveries during testing — for example, one a week — instead of fixing things continuously. Testing a system that keeps changing under your hands makes every result unreliable and every report debatable.

Launch, Support, and the Way Back

1. Decide how you launch: all at once, one department at a time, or in parallel with the previous system for a set period. Running in parallel is safer but doubles the work, so it needs a written end date.
2. Establish who's responsible in the first few days, where to write in, and how quickly they respond. The first two weeks generate more questions than the rest of the year combined.
3. Define the way back: under what conditions you roll back, who decides, and what happens to the data entered in the meantime. If this answer doesn't exist, the launch is a gamble.

What This Guide Doesn't Cover

This guide covers accepting processes with a predictable outcome: given an input, the system must do one precise thing, always the same. Verifying systems that respond probabilistically — assistants and automated responders, where the same question can get different answers and correctness is a matter of degree — requires a different method, covered elsewhere. Choosing what goes into a system's first version also has its own dedicated guide.