Acceptance Testing Sounds Easy, But Is Hard to Get Right
summary
Talk argues that acceptance tests must be concrete: executable examples, not vague prose. Demonstrations include an auction scenario and an authorization suite, an HTML export of C# acceptance tests printed for business review, and a live Mirror board with ~74 participants. Advice: prefer the smallest test that gives real safety (not always UI), invest in test infrastructure, keep specs refactoring friendly, watch when given when then or machine specifications add noise, and use the paolo test as a readability check.
AI-written summary · about
chapters (17)
- 0:00Acceptance testing challenges
- 1:24Poll on testing perceptions
- 4:53Social barriers in testing
- 6:41Testing vs checking
- 8:05Test myths debunked
- 11:34Acceptance test purpose
- 13:41Behavior Driven Development vs Acceptance Test Driven Development
- 17:13Good acceptance test traits
- 27:12Reviewing test examples
- 33:31Automating tests effectively
- 39:10Next steps
- 41:22Handling failing tests
- 44:28Refactoring-friendly tests
- 45:57Engineering mindset
- 46:41Selling to management
- 48:06Audience commitments
- 49:10Q&A
related talks
31mEschew Obfuscation and Omit Needless Words: Writing Clear Acceptance Tests
33mMore Than Automation: How Good Acceptance Test Can Make Your Team Happier
01h 01mAcceptance Tests, BDD & GO
41mOutside-In Testing
48mA Reflection on Software Testing
42mHow a Tester Can Help Improve the Quality of Requirements
57mAdvanced Testing Techniques: Tips from the trenches
48mBDD - It’s More Than Acceptance Tests