Should an acceptance test cover requirements that resemble specifications?

Question

I am trying to clarify the difference between Acceptance testing vs System testing, which has led me down the road of separating validation from verification activities. So, I am focusing on business use cases to drive an acceptance test. It seems only validation activities should be in the Acceptance test, but it seems some verification might be a good thing. It seems not so clear as to what to include as a question vs. supplying some kind of system report.

I have different requirement types and am generating use case diagrams to cover them. Some of the requirements I have represent specifications, or are rather specific shall statements, and I am not sure if they belong in the ATP, it seems they should be solely in the System test, not Acceptance test. Should I list these specifications in the ATP and have the user verify compliance (although verify usually belongs in the system tests) or leave them out of the ATP all together?

Requirement resembling specification example:

• "the x module shall display all date fields in the following format mm/dd/yyyy"
• "the x view should not display closed items"

Answer 1

The main difference between Acceptance and System testing is that Acceptance testing should be (in ideal world) defined before coding started. It is a suite of requirements/use cases agreed with customer, which must be passed to accept product. It is a part of "business". System test - it is a part of personal responsibility/quality of project QA. So, you could leave a lot of requirements out of acceptance test suite, but ATP (in general case) should be accepted by customer before execution.