Software Tester vs User Acceptance Test
Probably as you can imagine I'm new to Software Testing. Our group is about to test our first mainframe application and we are very excited about it. But we found the first stone in our way, the user. They say if they are already doing the test and the acceptance they don't understand what is the difference between their job and our job.
Please somebody verify my answer and help me out. Here is my answer.
We are resposible for the creation of all the test plans and test scripts needed for the test process. (we don't do unit testing)
We do all the testing that is necessary to crash the system or to prevent a bug to skip into production. We do the test from a different point of view, not like the developer or the user.
We are also responsible for an efficient defect track system, report them, give the appropiate follow and report them to management and to the user.
After we repeat all this steps and we feel that the system has been tested then we release the system to the end users so they can start the user acceptance testing and we can work together in this part of the cycle.
And at the end we are not the ones who decides if the system can be installed or not, that's the responsability of the user acceptance test. We only report the findings during the test, what has been tested and what was not, what was corrected and what was not. And then with all this information the management has to make a decision.
After all this they still think is an overlaping effort.
Please let me know if this is ok and if anything is missing.
[This message has been edited by hfgerena (edited 09-14-2001).]
Re: Software Tester vs User Acceptance Test
Acceptance testing is always a difficult thing to manage, whether you are a software services company or in-house IT shop. In recent years, I have tried to get customers away from the concept that they accept the system by the use of extensive Acceptance Testing.
When I first started in this testing game, a seasoned Test Manager said to me "Getting acceptance is like selling a used car - you want the customer to read the service history, examine the logs for the car, kick the tyres, honk the horn and drive it away". If you think about this analogy, what it means for software is that the customer needs to know that the software has been properly put together, properly tested and, therefore, has a high degree of confidence that the software will work and meet the requirements well before acceptance testing comes along. Then, at acceptance test time, all they need to do is a short test to assure themselves all is OK and they can put it into production.
I try to avoid the phrase "Acceptance test" when talking to customers. What I want, and the company wants, is for the customer to Accept the product. This is done by ensuring that they are involved in the requirements (obviously!), they review and sign off the Functional spec, design specs, Test strategy, test cases, test results. They are involved in reviewing problem reports, they attend progress meetings (technical as well as contractual) and they are fully informed about how the product was put together. Assuming all is going well and the customer has put the effort in to keep up with the project, then the level of confidence in the delivery will be high and the acceptance test becomes a small part of the act of "Accepting the Product".
Acceptance testing should be about ensuring that the delivered system supports the business processes, not that the system works (you have already done that in System testing). If the business focuses on that, then there will be no overlap. Naturally, they will be exercising the system when they do this, sometimes in the same way that you have in System Test, but they will be viewing it from a Business perspective. The question they should always be asking is “Can we do our job with this, according to how we specified in the Requirements.”
Re: Software Tester vs User Acceptance Test
My opinion is that user acceptance testing is testing the business functionality of the system. In most cases they do not have the proper background to perform the same testing that we do. If they did and they did the same testing we did then I don't believe that would be an appropriate use of their time. They need to be focused on business issues and not testing issues.
Our testing is much more in depth, as we all should know