Why clicking around is not enough

Spending an hour clicking through the application after a migration finds the loud problems: a window that will not open, a button that does nothing. Those are not the problems that cost money.

The expensive faults raise no error. They produce a wrong amount on an invoice, a date shifted by a month, or an email that never left. You do not find those by clicking around — only by comparing deliberately. We wrote a separate article about it: what silently breaks in a 4D migration.

What a representative test environment means

Testing against an empty database with three fictional customers proves nothing. An environment is only representative when it resembles the place the application will actually run:

• Your real data, at its real volume. Silent faults live precisely in the exceptions a test set does not contain: the customer with an apostrophe in their name, the invoice from 2009, the file with five hundred lines.
• The same regional settings as your users have. Number and date formatting depends on them, and a test machine is rarely configured correctly.
• The same peripherals. Printers, scanners and point-of-sale hardware behave differently from their counterparts on a development machine.
• The same integrations. Mail server, accounting package, web shop. Anything running through a test address or a simulation has not been tested.
• The same operating system your people will actually be working on.

The faults live exactly in the differences between your test environment and reality. The smaller those differences, the fewer surprises after the switch.

What structured testing involves

• Written scenarios instead of “trying a few things”. Anyone who follows the same path twice can compare results.
• Old and new side by side. The same operations on the same data, in both versions, then comparing the output line by line. This is the only method that reliably surfaces silent faults.
• Recording what was tested. Not only what went wrong but also what went right — otherwise, by the third round, nobody knows what had already been checked.
• Retesting after every change. A repair in one place regularly breaks something in another.

How we help

You do not have to do this alone. We either take the testing on ourselves or guide your own people through it — whichever fits your organisation:

• Setting up the test environment: a working copy of your data, with the right settings, peripherals and integrations.
• Writing test scenarios based on your actual processes, rather than on whatever the software happens to be able to do.
• Running the comparison between old and new version, and chasing down every difference until we know where it comes from.
• Guiding your people who carry out the tests. They know the process; we know the pitfalls.
• Reporting: what was tested, what was found, what is still open — so you decide on evidence whether to switch.

Your people know the process, we know the pitfalls

The best tests come from the people who work with the system daily. They know which exceptions exist and which report has to be right on the first of the month. What is usually missing is the structure around it: what do we test, in what order, and how do we know the answer is correct.

We do not replace your people. We give their testing a shape in which it actually proves something.