Getting What You Want: The User Acceptance Phase

You’re nearly there now, with an application you can deploy and/or sell – even rent in an SAAS configuration – whatever your plan is.

There’s just one final hurdle to get to the status of User Acceptance Confirmed in the software development life cycle – making sure that it really is what you want.

This is the last of our posts in the series How to Ensure Software Project Success and in this post about User Acceptance Testing, UAT, we will be outlining how you can run an efficient and effective UAT process to ensure that the approved version should at least be the minimum viable product, MVP, for you.

Your development team has told you that the software has successfully completed their QA process.

What Happens After QA Process is Completed

  1. A production environment is built
  2. The UAT team is mobilised
  3. The UAT team executes the UAT plan
  4. Issues and defects are recorded, analyzed and categorized
  5. The software is formally accepted by you

Let’s look at each of these in more detail.

1. A Production Environment is Built

Depending on your application and architecture this may be a simulated production environment (for example using simulated connections to a credit card merchant service – called a ‘stub’) or a fully live environment (with the exception that it would not be accessible to your full target user community).

Some of these factors will be accounted for in the User Acceptance Test Plan, where the UAT environment should be described in detail.

For example, a typical web application to be tested might reside in a subdomain of your main site during the UAT process.

2. The User Acceptance Test (UAT) Team Mobilises

You will need to have your Users – maybe not all the Stakeholders, but most of them – represented on the test team, with a set of tests, or, ‘scripts, to carry out.

This includes representative test data – which you may already have prepared and supplied to the development team to assist them with their own testing.

The test scripts will be based on the User Stories that were developed in the earlier stages of the project.

3. The UAT Team Executes the UAT Plan

This will usually be done with a Business Analyst and Development Team Leader close to provide test support.

Executing the test scripts will be done following an overall test plan with sequencing which follows the business processes.

Depending on your application, there will be a range of types of testing: functional, non-functional, integration, performance, stress and so on.

It is essential that one person is responsible for managing the UAT.

4. Issues and Defects are Recorded, Analyzed and Categorized

The UAT team will need a database or spreadsheet to record the test results and identify defects/test failures with a severity level – usually Critical, Moderate and Low severity.

Issues should be discussed with the Business Analyst and Developer Lead as they are identified.

Some of the issues will simply be misunderstandings either in design or operation, but these should be few in number. Others issues may be more serious – and even fewer in number, but rarely zero.

Certainly there should be no ‘show stoppers’ at this stage. Some ‘patches’ – updates – may be required to the software during this process, depending on the issues at hand.

Other issues may be scheduled for inclusion in the next version release or ‘maintenance update’.

Whether you use a smartphone, tablet or desktop yourself, you will certainly be familiar with the software update (fixes, small functional increments) and upgrade (significant functional and non-functional improvements) processes.

5. The Software Project is Formally Accepted by You

At the end of the UAT process, you will take a long hard look at the results and then decide whether the software meets your expectations for the MVP.

Be realistic and pragmatic – not everything will be perfect at this time, but there should be a clear plan to address any issues.

You might consider overall acceptance criteria as being:

  • No showstoppers (critical issues)
  • fewer than 3 moderate severity issues
  • less than 20 low severity (or cosmetic) issues

Image Shows Example of UAT Issue Tracking: a User Acceptance Test Log

User Acceptance Test Log

Setting these criteria depends very heavily on the type of application.

For example, if you employ all the users yourself and there are relatively few of them, then you might be more relaxed about issues than a case where your app is exposed to 10,000 public users on day 1 when errors could have huge reputational and business impact.

Each case is unique and you will need to weigh up the pros and cons as they relate to your business needs.

The Future

So, you have now formally accepted the application, probably with an agreed plan to fix some issues in a maintenance update soon after the first formal release – the cutover to the live operational application, Version 1.

This version will be in a maintenance phase as far as your development partner is concerned, but Phase n+1 – the next upgrade – may already be taking shape, building in more functionality – the Should Haves that didn’t make it into the earlier version.

Closing Words

I’ve now come to the end of this series and you should have a reasonable understanding of ‘How to Ensure Software Project Success’.

I’ve only skimmed the surface of the SDLC and project processes but if you follow my advice then you should get what you want at the end of the project.

Obviously there is a lot more behind these steps, and experienced professionals are essential for operating them effectively to deliver a successful outcome. And, if you are looking for an effective, efficient and agile project partner, then contact Visichain today for a free consultation.

In any case, be sure to follow our blog and learn more tips and techniques for successful software development.