UAT Is the Final Frontier
If Space was the final frontier for Captain James T. Kirk, then for any Software ‘Enterprise’, the test for user acceptance is the final frontier of software testing. Beyond the final frontier, there are two universes.
- One where life is easier because everything goes as planned, requirements are met with great results every time.
- The other is a world of nothing – unexpected results that are the result of everything being incomplete and dysfunctional.
Sound vaguely familiar? – We have all visited both at some point.
So, who is this UAT savior of the universe?
Here is a definition of the term User Acceptance Testing taken from the ISTQB Glossary of Testing Terms:
“Formal testing with respect to user needs, requirements, and business processes, conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.”
There are three important aspects to this definition
- UAT requires ‘formal testing’, which means that tests should be designed and executed in a structured way that provides objective evidence of the acceptability or otherwise of the system.
- Testing should be carried out with respect to ‘user needs, requirements, and business processes’.
- ‘Acceptance criteria’, which define what is acceptable to the users, should be defined and tested against.
UAT’s role is to determine, from the user perspective, if the system is indeed fit for purpose and is required, because code is often produced, based on the developers own requirements document and this may not actually be what the client needs from the software.
When requirements change over the course of a project, they must be communicated effectively to the developers. So looking at the V-model where UAT corresponds to the Requirements Phase of the SDLC, we can see where the problems may arise. (We’ll save UAT in Agile for another day!)
How do we test for User Acceptance?
As already stated in the definition above, UAT is performed by analyzing the documented experience and overall satisfaction of the system or software’s intended users.
Entry criteria for UAT must be satisfied before UAT commences:
- Business Requirements are made available.
- Application Code is fully developed.
- Unit, Integration, System, and Regression testing stages are complete with the only known unresolved defects being strictly cosmetic.
- All the reported defects should be fixed and tested before UAT
- The UAT Environment ready
- The testing team has confirmed that the system is ready for UAT
The following are the tasks need to be performed by the test team
So UAT goes well and we are ready for production – right?
Hold on one minute!
Before moving into production, the following needs to be considered:
- Are all critical defects closed?
- Does the business process work satisfactorily?
- Have stakeholders signed off on UAT?
- How will the transition to live use be managed?
Once this is done, take a few deep breaths and bring up that service, and relax.
Good job UAT!
With UAT, the customer can be sure “What to expect” from the product rather than assuming. The benefit of well-structured, formal UAT is that there will be no surprises when the product after its release to the market.
Why we do it:
- Risk management – avoiding expensive failures
- Confidence building – achieving expected business benefits
- Assessment – getting the business processes right
- Preparation – assessing if the service is ready
With UAT in place we should no longer need to ‘boldly go where no man has gone before’
………Beam me up Scotty!
By Mark McGuinness, Lab Manager – Olenick & Associates, Belfast