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?
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".
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".
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With