Types of User Acceptance Testing
The concept of User Acceptance Test is straightforward, UAT is a process to verify that the software developed works per the user’s requirements and preferences. A real-world environment, sometimes even a live environment, is used to test the software. Bugs, flaws, and missing functionality are detected and developers make changes and repairs. There are number of types, or branches, of User Acceptance Testing including:
- Alpha and Beta Testing
- Contract Acceptance Testing
- Regulation Acceptance Testing
- Operational Acceptance Testing
Alpha and Beta Testing
A controlled or development environment is used for this type of testing. Though end-users might be involved, most often this is not the case. Internal staff or the development team performs this testing, normally long before the product is known to outside customers or testers. A small user group can also perform the test but the important part is the controlled environment that is used. Once Alpha testing has been completed and the bugs and issues fixed, the software then moves on to the next step.
Also known as field testing, Beta testing employs genuine end-users to perform this test with the goal of collecting feedback for further improvements. Rigorous testing and communication is required to ensure that the issues are not only detected but also fixed. The most important aspect to Beta testing is that an uncontrolled environment be used at all times. This phase of testing is the most difficult to manage as it involves lots of different resources from potentially more than one company.
Beta testing is regarded as important as it provides the end users a first look at the software they will be using a foundation is thus formed for further improvement and bug fixing at both the developer and end-user levels.
Contract Acceptance Testing is defined by the contract signed between the software buyer and the developer, obviously this type of testing is only conducted when the software is being modified or created by a company for an external customer. The term is formally defined within the contract so that no ambiguity remains. There are two ways to conduct contract acceptance testing, each depending upon the contract signed:
- Before the software goes live
- After the software has been live for a pre-determined period of time
These tests are also important to verify that the developers have fulfilled the requirements of the contract but also that the system under test can be used in the real world, this may overlap with the OAT phase discussed in a subsequent paragraph. That these tests may trigger payment, is another factor that is associated to this kind of testing and makes this phase important as payment is only released if all the contractual obligations are fulfilled.
A Service Level Agreement (SLA) is another important aspect of contract acceptance testing. SLA comes into play if the contract acceptance testing is done after service goes live. SLA refers to the service delivered rather than the mechanism by which it is delivered. If the service works in-line with the requirements of the user, then it means that contract has been fulfilled. This part of UAT is then considered fulfilled and the user fulfills any obligations on their part as mentioned in the contract.
Regulation Acceptance Testing (RAT) can also be an important phase of UAT and the salient features of this phase are also mentioned in the development contract. It is an obligation to be fulfilled by vendors or developers, regulation acceptance test is also known as compliance acceptance testing. Applications and software programs are being developed all over the world and every country has different rules and regulations about the development process. Governments have defined the rules and regulations but at times, unintentionally, they may be violated. The user has nothing to do with it and the vendor is the one that is held responsible.
Regulation acceptance testing therefore ensures that the rules and regulations of the governing body are fulfilled. All legal regulations are also fulfilled under this part of the contract and payment is also associated with this phase, which is only made once the test is passed. The rules and regulation of this phase of UAT are also defined in the contract and each clause is gone through as the phase advances. Failure means that the software cannot work in certain region or country which may have a negative effect on business.
Operational Readiness Testing (ORT) is the aspect of the quality management system associated with acceptance testing phases. An operational environment is simulated to ensure that bugs are detected so that the software is further developed and improved. The majority of this testing is non-functional in that it is looking at the operational capacity of software not specifically missing or incorrect functional requirements. The operational staff usually performs this testing and provides feedback whilst performing simulated, or sometimes actual, day-to-day operation of the business.
ORT is also often linked to the payment process and the different operational efficiencies to be added to the program are listed in the contract. Whether these specifications are added to program or not, are tested and verified by the operational staff. In case of failure, a “No-Go” call is given until the issues are entirely fixed. ORT is also linked with the technical compliance of the organization. Some important aspects that are checked in this phase are:
- Memory usage and performance
Changes in a simulated operational environment are also done and their effect on the software is determined. The program is then tweaked to best fit for the organization.
UAT is a vital part of the overall software development process, and although it uses the highest and most diverse number of resources, it is often the most unplanned and poorly coordinated of all the testing phases. Tests are formed not just by keeping in mind, “what does the software do?” but also by “What do I want the software to do?” and perhaps the most important “Will this work in the real world?”.
Although the aforementioned testing types don’t include all aspects of User Acceptance Testing, they do represent the core testing processes used for most software releases.
Alpha Testing is done by the internal staff of the company. It can also be done by potential user group, provided is conducted in the development environment.
Beta testing is usually conducted by real end-users of the product. The feedback obtained from genuine users helps in the further improvement of the product.
Contract Acceptance Testing can be conducted in two ways:
- Before the final product version is released.
- After the software is deployed for a pre-determined time.
Regulation Acceptance Testing is conducted to make sure that product fulfils all prescribed regulations of the governing body. It ensures that the software complies with all legal regulations.
Types of User Acceptance Testing The concept of User Acceptance Test is straightforward, UAT is a process to verify that the software developed works per the user's
An unique solution for Application Quality Management (AQM) - Qualify The quality of an application or software delivery is at the heart of many of the challenges faced
Intelligent database management and verification Total application quality for SQL Server, Oracle and IBM iSeries TestBench is our solution that uniquely addresses
Robust test automation for everyone For short and long term success, software testing solutions need to be dynamic, flexible and able to be deployed easily and quickly
Dynamic manual testing 100% automation is not normally achievable, and whatever level you hope to achieve, you still have to get there from a manual start. With manual
TestDrive-UAT makes user acceptance testing as easy as child’s play TestDrive-UAT goes to the heart of the UAT pain making the automatic complete documentation of