Acceptance testing is meant to confirm that your system operates the way you want it to, but poorly written tests will disguise mistakes and give you false confidence about the system’s performance. You don’t want to find out in the middle of your daughter’s piano recital that your building loses hot water every time the boilers stage up.
Well-written tests have a few things in common:

• Detailed instructions: The test steps should be clear so that your tester doesn’t have to guess how to command the system, potentially compromising the test intent. Good instructions also make the test repeatable by another person in the future and provide the first step in a test failure investigation: Did the tester follow the instructions?
• Specific expectations: The precision of a test script comes from the detail in your documentation, so start with clear expectations. What should happen, and how will the tester observe it?
• Isolated variables: The more complex your sequence, the more critical this is. Make sure you’re testing a single behavior at a time by constraining other conditions that might affect the outcome. Consider all exception modes that might activate during your test, and remove them from the equation with operator overrides.

Passing a poorly written test provides no value to the project team other than checking a box in the TOP. Write better tests to catch problems when the stakes are low and the right people are already present and contracted to help.