| || |
- 1 Post By dlai
- 1 Post By meridian_05
Difference of Functional Testing in UAT and in System Testing
I searched for post relating to difference of UAT and System testing and have not seen something that answers my questions in mind. To start of I have no proper experience yet and I am just basing answers from books.
I have read books defining both test phases. So can you guys check if i got these correctly?
To simplify. System testing is to test the whole system based on specifications and UAT is testing the whole system based on business requirements
I have no experience doing both, Yes, I know that both are separate test phases, I would like to know in what way these two would be different based on practice and in hese aspects:
In what way they are different with the nature of test cases? Does both use techniques like BV-EP, atate transition testing?
In what way they are different if both are functional testing? Does this mean same set of test cases are just used, and are executed only in different environments?
Thank you very much!
UAT, User Acceptance Testing, the keywords here are 'User' and 'Acceptance'. The testing here is done by a proxy of the user, whether it's a focus group, a customer board of directors, or a business analyst, the keyword here is 'User'. The 2nd keyword 'Acceptance'. You are not testing quality, or in other words correctness of the software, rather, how well the solution fits the user's needs.
How UAT differs from say functional testing, is generally you are testing prototypes and mock features. The key goal here is to vet out assumptions in things like user flow and information architecture problems that are more costly to fix before the developers write their first line of production code. A common activity to do is to demo prototype features, for alpha releases, before developers invest the time in scaling, hardening, and any refactoring needed to implement the feature in a less hackish way.
In functional testing, you have test cases that outlines how the software was designed to work. While in UAT, you'll opt to having more higher level scenarios for the 'User' to perform, and from that generate requirements.
This really sheds light! Now I am starting to understand why enhancement reports come from this phase! ' how well the solution/system fits the user's need'
Originally Posted by dlai
Now I have a followup question, so functional testing in system testing would be more thorough and would have low level test cases right? Error messages and 'functionality' check is done here. So example facebook for upload photos functionality - system testing test case would be:
Originally Posted by dlai
1. Verify pictures can be uploaded individually
2. Verify pictures can be bulk upload
3. Verify max file size upload limit
While functionality - UAT testing test cases would be:
1. verify user is able to upload photos (high level and its up to the user to do bulk upload or individual upload, should the user see that bulk upload cannot be done then they may request it as enhancement right?)
I am quite aware that in system testing, some also do backend testing to check if integration or passing of data from one module to anotherr would be correct, but of course that would depend on the project test plan if that is on scope. So if the scope of testing is mainly on functional test cases for system testing, then functional testing would just be done front end right?
I have not really seen test cases from a real or proper UAT project so I really am not able to tell yet from a practice point of view. Do you know any links or sites showing test cases of system testing and test cases from uat both from one project as to see difference of how both were developed?
Usually, but not always. You are correct that this will depend on the test plan/strategy, particularly with the naming and scope of your "intermediate" test phase(s). Some projects will have Unit Test - System Test - UAT, some will have Unit Test - System Test - System Integration Test - UAT, and in others you will find that what they call System Test is in fact a System Integration Test anyway.
Originally Posted by sqatesting808
If the scope of your system test is end to end or point to point then it is possible that it will cross modules or interfaces. In these cases you may not have yet created any batch jobs or automation to run the interface so part of your system test will include manually running the process chains to move data from one system to another. This would be expected to be automated and invisible to an end user in UAT. As an example, I've tested one system where a file is uploaded to a GUI, passes through to a content management system, that passes the metadata to an SQL database, which passes the metadata to an intranet portal. When system testing we test each level of interaction to ensure the data is correct at every stage, but the user in UAT only sees the file go in one end and appear at the other after x amount of time.
As a system tester, in order to separate yourself from other purely front-end functional testers it would be worth spending time learning the technical insides of the system/app that you are testing, looking at the architecture of the system and any languages used in building it.
Different projects will have different ideas about what constitutes test cases, and what constitutes a System Test or UAT test case. Past projects I've worked on have created a library of unit tests, which were strung together to form system tests, from which user tests were selected. The difference in these projects has been the environment mainly - code was batched into a mock release, released to a standalone UAT environment as a dummy run for Production, and the UAT was run on production-quality data with correct user authorisations, and the UAT was highly detailed with formal test steps.
Originally Posted by sqatesting808
Other projects I have worked on have had detailed test cases for system testing, but used User Stories for UAT, where the business testers selected an "Actor" they wanted to be in the system and went about their daily routine without a formal test script.