Secrets to Automated Acceptance Tests


buttons from one screen to another, or to completely change the workflow in hopes that the application will be more efficient. There may be no underlying business-rule or system-behavior changes. But, these are the sorts of software changes that cause a cascading break in potentially dozens of acceptance tests.

You did the right thing by showing the software to your stakeholders, and your reward is both code to change and lots of tests to fix. No good deed goes unpunished.

Validate Frequently, Automate Verification After
It's the areas of our system that are subjectively evaluated that are most prone to change. Validating the user interface in particular is a subjective endeavor. Automating tests that verify this subjective stuff before the software is validated is risky. Because of their higher cost of construction, higher cost of change, and slower rate of feedback, I'd suggest automating acceptance tests after the software is validated and considered reasonably stable.

Please don't interpret this as a suggestion to defer automation until late in development. On the contrary, it's a suggestion to increase the rate of user and stakeholder involvement and validation. The sooner we validate, the sooner we can automate, and the sooner we can call our software "done."

About the author

Jeff Patton's picture Jeff Patton

Jeff Patton leads Agile Product Design, a small consultancy that focuses on creating healthy processes that result in products that customers love. Articles, essays, and blog can be found at Information about public classes, including Certified Scrum Training, can be found at

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!