User Acceptance Testing
User Acceptance Testing is the final stage of validation. This is the time that customers get their hands on the system (or should do) and the end product of this is usually a sign-off from the users.
One of the problems is that this is rather late in the project for users to be involved – any problems found now are too late to do anything about them. This is one reason why Rapid Application Development (RAD) has become popular. Users are involved earlier and testing is done earlier.
However, the users should have been involved in the test specification of the Acceptance Tests at the start of the project. They should also have been involved in reviews throughout the project, and there is nothing to say that they cannot be involved in helping to design System and Integration tests. So there really should be no surprises!
The approach in this stage is a mixture of scripted and unscripted and the model office concept is sometimes used. This is where a replica of the real environment is set up, for example a branch office for a bank or building society.
Why should users be involved
It is the end users’ responsibility to perform acceptance testing. Sometimes the users are tempted to say to the technical staff: “You know more about computers than we do, so you do the acceptance testing for us”. This is like asking the used car salesman to take a test drive for you!
The users bring the business perspective to the testing. They understand how the business actually functions in all of its complexity. They will know of the special cases that always seem to cause problems. They can also help to identify sensible work-arounds, and they gain a detailed understanding of the system if they are involved in the acceptance testing.
The differences between system testing and acceptance testing are:
Done by users, not technical staff;
Focuses on building confidence rather than finding faults;
Focuses on business-related cases rather than obscure error handling.
Contract Acceptance Testing
If a system is the subject of a legally binding contract, there may be aspects directly related to the contract that need to be tested. It is important to ensure that the contractual documents are kept up to date; otherwise you may be in breach of a contract while delivering what the users want (instead of what they specified two years ago). However, it is not fair for users to expect that the contract can be ignored, so the testing must be against the contract and any agreed changes.
Alpha and Beta Testing
Both alpha and beta testing are normally used by software houses that produce mass-market shrink-wrapped software packages. This stage of testing is after system testing; it may include elements of integration testing in the large. The alpha or beta testers are given a pre-release version of the software and are asked to give feedback on the product. Alpha and beta testing is done where there are no identifiable “end users” other than the general public.
The difference between alpha and beta testing is where they are carried out. Alpha testing is done on the development site – potential customers would be invited in to their offices. Beta testing is done on customer sites – the software is sent out to them.