Tests others can run and trust.
WHAT A TEST CASE NEEDS
A clear purpose Preconditions Steps, unambiguous Expected result, specific The data used
WHAT MAKES EXPECTED RESULTS POOR
Vagueness: the page loads correctly.
WHAT TO WRITE INSTEAD
Exactly what should appear, or be true.
WHY
Otherwise two testers reach different conclusions.
WHAT MAKES STEPS POOR
Assuming knowledge Combining several actions Depending on previous tests
WHY INDEPENDENCE MATTERS
Tests depending on order fail confusingly when one is skipped.
WHAT TO KEEP EACH TEST TO
One thing being verified.
WHY
A failing test should identify what is wrong, immediately.
WHAT TO NAME TESTS
After the behaviour verified, not the function called.
WHY
The name appears in failure output, and should explain what broke.
WHAT TO AVOID
Tests so long nobody runs them Tests verifying implementation rather than behaviour Tests that pass regardless of the code
WHAT TO CHECK
That the test fails when the behaviour is broken.
HOW
Break it deliberately, once.
