Welcome back to the Greyloud University Course, where we pass on the benefit of our huge experience in successful software development.
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 lifecycle – making sure that it really is what you want.
This is the last of my posts in the series ‘How to Ensure Software Project Success’ and in this post about User Acceptance Testing (‘UAT’), I 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 next
• A production environment is built• The UAT team is mobilised• The UAT team executes the UAT plan• Issues and defects are recorded, analyzed and categorized• The software is formally accepted by you
Let's look at each of these in more detail.
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 if 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.
The User Acceptance Test team is mobilised
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 (‘scripts’) to carry out, including 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.
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.
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 will simply be misunderstandings either in design or operation, but these should be few in number. Others 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.
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 and less than 20 low severity (or cosmetic) issues.
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 if your app was being 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 please contact us today.
In any case, be sure to follow our blog and learn more tips and techniques for successful software development.
