System testing vs Acceptance testing - Difference in test cases [closed]

Question

I'm a bit confused about the real difference between system testing and acceptance testing. When I search this topic the answers differ and I fail to see how the testcases can be vastly different.

Facts I've discovered:

System testing is conducted on the complete system and is done by the supplier. System testing is end-to-end testing where you test complete flows in the system (from login to logout) based on the requirement spec (both functional and non-functional).

Acceptance testing is done by the customer to verify that it meets the customers demand. This is also complete flows and is based on the requirement spec. HOWEVER the system that is built was designed based on the requirement spec and the apperance/usability is usually already accepted in the earlier stages of the development cycle. If the system covers the requirement specification it should not be possible for the client to say "this is not what we wanted, redo this and that", unless ofcourse the contract allows this and the customer is paying per hour.

So, my question is basicly, how would the test cases for these two test phases differ? Both of them is end-to-end testing and focuses on that it is a functional system and it satisfies the specification, which in extent is also the business needs (since it's what they have ordered). It seems as if the test cases from the system testing can be reused in acceptance testing as they both coveres complete flows?

Nates

Answer 1

The short answer is this:

System testing Performed by developers and/or QA to ensure that the system does what it was designed to do. This can be done automatically by using, for instance, something like Selenium (for a web app). The purpose for doing this is quality assurance, and many organizations don't bother with this.

Acceptance Testing Performed by customers and/or managers to ensure that the system does what they think it should. It is generally considered the end of the developers contractual obligation to fix the software.

The difference is that a system test will usually test things that the customer doesn't really care about, Things like "Are database connections committed in the correct order". Acceptance tests usually focus on things like "How is the subjective user experience".

Numeration

Wikipedia: "Unlike Unit and Integration Test Plans, System Test Plans are composed by client's business team". I'm not sure but it if my understanding was correct, your answer is in contradiction with the Wikipedia article about the V-model. Please inform me if you think the article is wrong or if I misunderstood your answer. en.wikipedia.org/wiki/V-Model_(software_development) – Protoactinium

You misunderstood my answer. Probably because the wikipedia article is using the word clients, while I use the word customer. I also included that occasionally it is done by a manager (or product owner if you want), because not all software in the world is developed for a client or customer. Some is developed in-house. – Lopes

Answer 2

Acceptance testing by the customer shouldn't really have formal test cases. It is all about the client using the system as they had planned to and seeing where their understanding of how it would work matches what it actually does. Test cases constrain the acceptance testing because typically things raised from it are like "X is great, but can you also add Y" and "We said field Z should be an integer but actually we may need to put text in there too".

Giesecke

I disagree. Acceptance tests should most definitely have a formal test case, otherwise you give the customer a "Get out of writing stupid requirements free" card. – Lopes

I'm thinking that the base of every contract between a customer and supplier is the requirement specification. If the customer is acceptance testing ad-hoc and is not testing the system using this specificaton as a base and accepts the system, they do not have a legal demand to come afterwards and say hey, you missed this. Both the customer and supplier should verify the that requirements are satisfied? – Nates

True, it cannot hurt to ask the customer to review the spec. It does sound a little like "we think this is what you wanted, please confirm that we have implemented it" rather than a more open "does the system do what you wanted it to do?" – Giesecke

Answer 3

Both types of tests are executed against the entire system/application. It's very possible many of the tests will overlap.

A system test is often executed by an independent QA team in a production-like environment. This may be the first time all of the components are tested together.

Acceptance testing is often run in either the same environment or a similar (also production-like) environment, but the make-up of the team often consists of a subset of the actual users of the system. One belief is that users will identify scenarios, defects, and observe behaviors that a regular tester would overlook. Also, this can provide a level of comfort to the users before they deploy to production.

If you are working from a V-Model, system test aligns with system level design and acceptance testing aligns with business requirements.

Luminal

"A system test is often executed by an independent QA team in a production-like environment. This may be the first time all of the components are tested together. " Aren't the component already tested together in the integration test? – Protoactinium