This chapter highlights Acceptance Testing as a key tool for reducing ambiguity and improving communication between developers and stakeholders.
The Uncertainty Principle
- Business teams want certainty about features; developers want certainty about requirements.
- Reality: Both sides often can’t be fully certain until development begins.
Estimation & Ambiguity
- Estimates aren’t precise—they are just educated guesses.
- Avoid premature precision; define details as late as possible.
Acceptance Tests: Defining “Done”
- Prevents confusion over when a feature is truly finished.
- Serves as an agreement between devs, testers, and business teams.
Key Aspects of Acceptance Testing
- Communication: Clarifies expectations for all stakeholders.
- Automation: Reduces costs and human error.
- Extra Work? Yes, but cheaper than fixing misunderstandings later.
Who Writes Acceptance Tests?
- Ideally: Stakeholders & QA, with developers reviewing.
- Reality: Whoever has time—QA, devs, or business analysts.
- Timing: Written just before development starts to ensure relevance.
Developers’ Role
- Work starts only when tests are ready.
- If tests don’t make sense, refine them with the team.
Acceptance Tests vs. Unit Tests
- Unit tests: Written by developers, for developers, defining internal behavior.
- Acceptance tests: Written for the business, defining system behavior.
Challenges with GUI Testing
- GUIs change frequently, making automated tests fragile.
- Solution: Treat the GUI like an API, and minimize UI tests.
Continuous Integration (CI)
- Run all tests multiple times per day.
- Failing tests must be fixed immediately—never ignored.
Conclusion
Automated acceptance tests are the best way to prevent miscommunication and ensure the software behaves as expected.