Testing: From Unit to User Acceptance

Testing, from unit to user acceptance. This lesson is about what testing proves, and who gets to say the system is accepted. The exam is firm on both.

The situation. A new system has passed system testing. The developers are happy, the defect list is short, and the project wants to go live this weekend. You ask who signed the user acceptance, and the answer is the development lead did, the users were busy. Then you notice the test environment was loaded with a full copy of last month’s live customer data, so the tests would be realistic. Two things are wrong here, and both are reliable exam points.

First, the levels of testing, which build on each other from the small and specific to the whole and business-facing. Unit testing checks the smallest pieces, individual programs, in isolation.

Integration testing then checks that those pieces work together and pass data correctly between them.

System testing checks the complete system against its technical specification, does it work as designed, end to end. And user acceptance testing checks the whole system against the business requirements, judged by the people who will use it. Each level assumes the one below it has passed, and the last one answers a different question from the rest.

That is the key. Unit, integration and system testing all ask, does the system work as built. Only user acceptance testing asks, does the system do what the business actually needs. And only the users can answer that, so user acceptance is owned and signed off by the business, not the developers.

Why not the developers. Because developers testing their own work can confirm it runs, but they cannot be the authority that accepts it meets a need they did not define. It is the same independence logic that runs through the whole course. And a system can pass every developer test and still be the wrong system, because system testing checks it against the specification, and the specification itself might have missed the business need. Accepting a developer’s sign-off in place of the users’ is accepting the wrong signature.

Now the second finding: keep live data out of test. Test environments exist to be poked at, so access is broader, change is looser, and the controls that guard production are relaxed. That is fine for test data. It is a breach for live data.

Copying real customer or employee records into a test environment exposes confidential and personal information to developers, testers and tools that would never be allowed near it in production. The risk is not that the tests are unrealistic; it is that real personal data is now sitting in a weakly controlled place. The fix is to mask or anonymise the data first, keeping its shape without exposing the individuals in it. When a question weighs realism against exposure, exposure wins.

And where does the auditor sit. The auditor reviews that acceptance happened properly, that the users tested and signed, not that the auditor performs the acceptance. An auditor who runs the acceptance test becomes a participant and loses the independent position, exactly as in the earlier lessons.

So hold on to the catch. A passed test is not automatically the right system. System testing confirms the build matches the specification; user acceptance confirms the specification matched the need. That is why both exist, and why the users are the ones who get to say the system is fit for use.

So carry this away. Acceptance is the users’ decision, made through user acceptance testing, never the developers’ sign-off. And when realism tempts you toward live data, mask it or manufacture it. Testing proves the system meets its requirements, and the users are the ones who confirm it does.