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

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.