I'm completely new to this stuff, and for what I've seen it takes a while to get used to it. I once tried, but felt I was spending way too much time just writing the tests, or just fixing them 'cause a big requirement changed.
So what are the advantages?
Anything that is automated should run the same way every time. When you're running it the same way every, single, time you are more likely to get results that compare to eachother.
If you're relying on non-automated tests to do these things, you greatly increase the chance you're not running the exact same test. It might be done with different steps or in a different order, which can effect the outcome of the rest of the tests. You also open yourself up to silly things like typos, mistakes, misclicks, coffee breaks, and confusion.
And for the most part, if you're doing it with a user, you're pretty much limited to using the UI. Your automated tests may be able to take advantage of your API in a more efficient manner (this is especially true for load testing. Loading up 50 UIs in could seriously drain your resources, which is an unnecessary drain when you're testing database performance.)
I'll start by saying that "automated" and "user acceptance" do not fit in the same sentence very well :)
The point of user acceptance testing is to have end users test your product in its final state as to validate it is doing what it has to do & it is doing it correctly. Human interaction just can't be automated (yet). The value that our human randomness & thinking give is simply enormous and this is a major disadvantage point for automated testing.
Off topic: If, by any chance you have a few automated real users lying around .. feel free to pass me one or two :)
In general you should use tests as a spec for your product. Changing the tests should be done as little as possible, unless you are making a change to your spec. And you should never change tests and code at the same time, otherwise you won't necessarily know if they are both correct. It is not uncommon for 'big requirement changes' to change the spec. I would write the tests before you ever start working on the code. And use these tests as a way to define when you are done making new code for some new feature. The idea is, once all the tests pass, you do not need to add any more functionality. If you have a pretty good test suite then it is much easier to change functionality while remaining confident that nothing else broke (assuming all the tests pass at the end). So if you are just looking for advantages, they are:
Automated tests save time and increase accuracy during regular execution of test cases over a long period of time. There is of course a trade off, since it takes a long time to create automated tests.
What has been mentioned in the previous post is very true. At my current project we use automated user acceptance test, we also use the same suit as build acceptance test. Since automated tests make sure each and every part of the AUT is as it was expected to be w.r.t the SRS, we can always be sure that both the functionality and GUI lay out is as expected. Automated tests even make sure that very minute cosmetic features are meeting its requirements if the tests has been created well. But it requires that the automation framework to be we well designed and flexible .
Acceptance testing is the final step of validating your product. There are certain advantages of acceptance testing. In fact I've got a guest post on importance of acceptance testing, hope might be useful and could be a good add to this question. Here's the link to article http://qainsights.com/what-is-acceptance-testing/
