I want to focus on the financial aspect of the acceptance testing. (A) and (B) usually do the acceptance testing together (I know I’m saying the obvious), and at the end of the test, (B) can either accept or reject the product, in the latter case (A) as to work more in order to deliver the product to meet (B)’s criteria. Acceptance testing is usually loathed by development companies and sometimes (I’ve seen it happening) (B) uses acceptance to its benefit, such not releasing payments, etc… When the acceptance is signed, it means that everything is OK with the product, and all outstanding funds have to be paid, and the product will then move from development phase to maintenance phase (where the monetary part will be handled by a different, ongoing contract mainly turning the customer into a cash cow).

I think acceptance testing are unavoidable, but usually both parties (especially the customer) use them for their advantages.

PM Hut – http://www.pmhut.com

@mark – the difference that I have seen in acceptance vs integration tests is that while integration tests are run in the same test suite as unit tests (ie nunit/junit/test runner) acceptance tests often use a different tool (eg JBehave, RSpec, Selenium, Watir/Watin). Because you are writing the test in a different tool set, for one you constantly need to switch between the different styles of testing. Also you tend to need to repeat your self in acceptance tests to bring the environment into a state in which you can start testing (ie implementing all the Given conditions first).
@toni – Have we really got sufficient tools now to get the customers to write functional tests? You may argue that JBehave2 aims to put this in the hands of the customer, but at the end of the day, the developers need to implement those tests. I have found that letting the business people specify the tests (ie they write given when then) and you take that interface and write the implementation underneath leads to inefficient tests, which means long build time which has a spiraling effect.

@all – thanks for the comments.

Dev writing tests is good, but not enough, making the customer writing tests we’ll ensure the system works as he really wants, not as we understood it should work.

I was thinking about unit testing and acceptance testing, the former helps bring quality into the product (and more) and the latter tests the product after its finished.

I have posted Deming’s 14 points here:
http://blog.jayanthan.com/2008/09/skip-to-content-w-edward-deming%E2%80%99s-out-of-crisis-ii/

I believe acceptance testing is a good way to keep track in what is important with one story for the whole team.

I focus on proving it works with integration/persistence/unit tests.

But… we cannot forget that we must have useful documentation… and maintainability is an important attribute in that way. So, if it is not working, the team need to figure out some other way.

In my current environment, not every test is approved to become automated, and even if approved, it’s based on a scenario, not a story.

I would be interested to find out what you see as the difference between integration and acceptance tests.