Five Reasons Not To Do UAT
Many projects go live without going through UAT, with a variety of reasons given to support the decision not to do so. Here are five reasons with a discussion of how they fit against the five project characteristics: Scope, Resource, Time, Quality and Risk.
1) The Project is Late
Lack of Time is the most common reason not to do UAT. It comes about because UAT is at the end of the development process, but the release date cannot be changed. The earlier stages of development have been delivered late so the time available for UAT is reduced – sometimes to nothing. To make the delivery date the decision is taken to not do UAT, so that the benefits of the system can be obtained. However if a system is late in development something else might have been scrapped or done inadequately and the most likely activities are going to be the testing stages. So the risk is: can the benefits of the system – the Quality – be gained from a poorly tested system?
2) The Business Expertise Cannot be Spared
UAT has to be performed by users, most of whom have other jobs within the organisation, and so are a scarce Resource. As these will be the people using the system it would seem logical that they would want to be involved. However when this reason is given it normally implies that there is a lack of ownership of the system by the organisation. This can mean that if they are unwilling to do UAT, they are also unlikely to try and make the system work when it goes live. Without business expertise UAT cannot be effectively done, any testing that is done will be a repeat of the developers’ tests, and unlikely to expose the key business problem areas. So the risk is: will the system ever be used?
3) The Staff Don’t Understand The New System
This reason implies the users wanted to be involved but they have been excluded up until the last moment when they are told that they have to perform UAT. This is again an issue of Resource available. They will have to learn all about a new system and test it simultaneously. They fear that if anything goes wrong with it when it is released they will get the blame for signing the system off. Not surprisingly they are upset. The lack of communication earlier in the development means the risk is that users will spend more time defending themselves then working to ensure a successful system release.
4) Faults Can Be Fixed When The System Goes Live
This reason is the acceptance of a large Risk against the assumption the Quality of the system is largely sound. It is normally a decision driven by the necessity to reach a release date, and insufficient time being available to do UAT. This approach can be justified if good system testing has taken place and the bugs within the system are known and been worked around. Of course if this has not happened then the risk of failure is larger. But the main problem with this approach is that there is no checking that the system will meet the user’s needs, as would have occurred if UAT had been done. So the risk is that the system will not meet the user’s needs.
5) It’s a Standard Package so does not need testing
A Commercial Off The Shelf (COTS) standard package is often employed as the solution to provide functionality. As this package is sold on the basis that it is used by a number of other organisations, the assumption is made that testing it is not necessary or is just a formality. This of course depends on how many changes have been made to the package. All packages have to be configured for the users, and some have major changes made to the standard functionality to meet the user’s needs. Both of these cases require testing to be done to see that the changes the organisation needs, and do not interfere with other functionality. Regardless of the changes the package needs to be checked to see if it meets the business needs. This is a Scope issue as the system might work perfectly but not do enough to meet the user’s needs.
UAT Cannot be avoided
These five reasons are not the only ones, but they are the common one. All of them increase risk of a system failing after acceptance by not checking it beforehand. It is strongly recommended that before deciding not do UAT a business risk assessment is done beforehand and signed off by all stakeholders. This will not stop a system failing, but it will make sure that everybody is prepared to take the risk of it doing so.
UAT Explained
- What Is UAT, And Why Do It? explains why UAT is different.
- UAT Definition is the formal UAT definition.