How detailed should a customer acceptance test be?

Question

Here is a test description, testing the \"Create New Widget\" use-case.

• Confirm that you can enter a new widget into the system.

---

Here is anoth

Answer 1

That looks more like a feature test plan to me (i.e. internal testing)

Acceptance testing usually refers to what you show the customer. I guess you could give the customer a test like that - good luck though

For user acceptance testing, i prefer a very simple format (of course, this probably wont be appropriate say for space shuttle software or banking). Its fine for small-to-mid web projects

The crux of it is; make a table which lists every page in the system, than make a column for the client to initial, and another one for yourself to initial. You sit with the client for a few hours and go through everything. If they are happy with a page, they sign off on it

For the full details of the template, see: User Acceptance Testing

Answer 2

The user acceptance test cases should be detailed and simple but not as detailed as your third example. Acceptance testing is about making sure the customer gets what they agreed to. If you simply say, "click this then click that, etc, etc..." that is more like a functional test. You are not eliciting users to verify that functionality meets the test case laid out in the acceptance test. You are only asking them to click through tests that you could have simply automated.

User acceptance tests should be more along the lines of "create widget, verify that it appears, delete widget, etc." This will also encourage users to seek out individual features and (as a side effect) flush out any usability problems you may have overlooked.

Answer 3

I think that your acceptance tests should primarily be good path tests. Sometimes the "good" path will ensure that errors are properly handled. You should have other tests that validate your security and exercise the corner cases, but an acceptance test is more about making sure that the correct application has been built than making sure that every possible condition is handled correctly. If you have good unit tests and use best practices, then I think that the good path testing is entirely appropriate.

For example, I wouldn't necessarily test that I don't have problems with SQL injection if I've used a technology that enforces parameterized queries or where I generate queries by hand (I don't), that the unit tests validate that injection fails. Addressing the corner cases in unit tests makes it less important to focus on them in acceptance tests. If you need to include a few as examples to the customer that your backend implementation addresses their concerns, then by all means do so, but I wouldn't test things that I know I've addressed adequately via other testing.