Feasibility of test automation depends more on purpose, benefit, maintenance and cost than whether a test is a user acceptance test (UAT) case or another type of test case. I review test cases considered for automation by thinking through the shelf life of the test case (how long will the test case be used) and whether test time and effort will be saved by automating the case. I also ask myself what benefit can be gained by automating the case. Often the benefit of automating is being able to test with a larger variety of data than could be accomplished manually but this benefit may have to do with the fact that most applications I've worked with have been data-centric. The benefits you discover could vary based on the type of applications you're working with.
Advantages of automating are that you can speak to the status of the test cases after each execution. A disadvantage is that automation never replaces a person's point of view or sense of comfort with a system and the true meaning of user acceptance may be lost by automating the test cases.
What's interesting to me about your question is that user acceptance cases are test cases usually created by users or written by testers or business analysts after interviewing users for the purpose of the users executing tests vs. automating the test cases. It might be that the test cases created for user acceptance are so practical and represent logical everyday use cases that automating the test cases makes sense. But if a user acceptance test case was automated, I don't think I would consider the test case a user acceptance case anymore. The test case would become an automated case written used to demonstrate system functionality.
If your situation is such that the users who are responsible to test a system after each release are too busy to test after each build and this is why you are considering automation, then I think there might be a different issue that needs to be addressed. Perhaps the user community is understaffed, or the expectations for user acceptance testing needs to be adjusted or there might be some other issue that needs to be understood and discussed versus automating to resolve an issue. I raise this as something to consider before spending effort on automation.
This was first published in October 2007