The automated acceptance testing paradox
summary
Claim: automated acceptance tests become a paradox when webdriver and Cucumber mark a degraded UI as “passing” because checks assert HTML not business perception. Evidence: examples of two webpages where automation accepts the ugly one, a built Chrome extension that fills forms to speed exploratory work, and experiments with API checks and approval testing. Recommendation: treat automated acceptance tests as guides not validators, pair them with exploratory sessions, three‑amigos collaboration, and targeted checks.
AI-written summary · about
chapters (25)
- 0:00Intro
- 2:30About Software Testing Clinic
- 3:40Context
- 5:33What is acceptable
- 6:37First screenshot
- 6:54Who thinks this is acceptable
- 7:51What are acceptance tests
- 9:37Why do we automate
- 10:35TDD
- 12:30WebDriver
- 13:53The automated acceptance testing paradox
- 14:47General Systems Thinking
- 16:38Organisational Complexity
- 17:37Deliver what the user wants
- 20:15Automations role
- 20:39Automated acceptance tests
- 21:02The failed check
- 23:50Testing activities
- 26:59Collaborative discussions
- 27:49Exploratory testing
- 28:52Automation in testing
- 32:27Wrapping up
- 34:04QA Questions
- 37:59Stack traces
- 39:17Collaboration
related talks
33mMore Than Automation: How Good Acceptance Test Can Make Your Team Happier
48mChallenges in UI Automation and How to Solve Them
46mPanel Discussion: Breaking Myths About a Career in Testing
04mWe're bad at web integration testing
45mTest Automation Without Assertions
43mYour Tests Lack Vision: Adding Eyes to Your Automation Framework
53mModern Web Testing: Going Beyond Selenium
28mAutomation does not replace collaboration