No one wants to be associated with a failure. In business, a close association with a major IT project that fails can mean you’ll be looking for a new job. ‘Testing’, I hear you say, is how we prevent such failures, but for me, testing covers all manner of sins, so let’s consider what really matters.
Does the new or enhanced application meet the current needs of the business?
That doesn’t sound contentious, although ‘current’ is often the crucible where the fires burn fiercest. There is an unavoidable lag between the project start, when the shopping list of requirements was created and the moment of delivery. Very few businesses stay still that long.
However, the statement is equally important in what it doesn’t say. It doesn’t talk about Agile, waterfall, test-driven development, or any other methodology or tools. Such matters are simply irrelevant if the application falls short of its goals or fails when deployed into a live environment.
That’s not to suggest for a moment that such choices are irrelevant, but it is important to realise that these exist to help you achieve the quality goal. They are neither a goal in their own right nor are they any guarantee of success. And while we’re at it, let’s consider another tablet of wisdom pushed by analysts such as Gartner but one that perhaps doesn’t stand up to examination.
Push Quality left
‘Push quality left’ recognises that it is better to find a problem sooner when it can be rapidly fixed by a developer rather than waiting until the deployed application fails with the associated massive costs and disruption. What can possibly be wrong with that? Only two fundamental problems that I can see.
Let’s start with the easy one. The majority of major applications are now purchased rather than developed. So how far left can you push quality? If you are an end user, your left boundary is the vendor help desk of your vendor project manager. So, you can either choose to accept that the purchased application will meet your business needs on blind faith, or you need to run a major verification exercise.
What is wrong with blind faith
But what is wrong with blind faith? How many of our companies test each version of Microsoft Office? What about Google’s normally automatic updates to its Chrome browser? Why not?
I think there are two dynamics in play here. Firstly, in comparison to a major business application, our use cases are very simple. Secondly, we know that both Microsoft and Google have massive customer bases, and cannot afford reputational damage but can afford the significant investment to ensure these applications operate correctly.
That is in sharp contrast to the applications that support your businesses, where the vendor will have considerably fewer resources and need to support a product with an almost infinite combination of configuration options.
What sort of Quality is pushing left?
The other fundamental issue with pushing quality left is perhaps less obvious but is equally important. What sort of quality are you pushing left? Is it testing that the partially built application actually meets the needs of the business? Of course not. It is much more likely that the focus will be on finding bugs so that users involved in the verification process further down the line don’t get frustrated by application crashes and operational errors.
Fit for purpose?
So how are we to ensure that the application meets the current needs of the business?
‘Current’ tells us what we need to get started as it defines the timing. The last test cycle before an application is deployed is the only one that matters.
If that sounds bold, let us consider why you are doing a final test cycle. You’re not doing it for fun. You’re doing it because either something has changed that fully or partially invalidates previous test results or that the testing to date has not given you sufficient confidence to go live.
This form of testing is normally called a user acceptance test (‘UAT’), the much-unloved member of the application delivery family. There are plenty of reasons why it isn’t the apple of its parent’s eyes, but we cannot ignore its importance – this is the activity that determines whether the application meets the current business needs. This is the last chance to avoid embarrassment, downtime, loss of business, and reputational damage to the business.
Let me propose that rather than tolerating, bemoaning, or avoiding UAT, it is time for a re-think. It is time for UAT 2.0.
The UAT process itself delivers significant benefits. Key users will be exposed to the new application and trained on its capabilities so they can support other users as the application is deployed and operational procedures can be streamlined based on the new application. And yes, there is the vital task of ensuring that the new application does meet the current needs of the business.
Time for UAT 2.0
It is easy to focus on the difficulties of running a UAT cycle, with users dragged away from their day jobs with the associated impact on the business, the fact that they are untrained in testing, that is hard to maintain motivation levels across multiple test cycles, that problems are poorly documented, and test coverage is very hard to track. All these issues are fixable, but we need to start with a PR re-branding exercise.
A new application that supports the current needs of the business is a powerful thing. It may deliver higher productivity, profitability or improve relationships with your customers. These are considerable benefits.
The UAT process itself delivers significant benefits. Key users will be exposed to the new application and trained on its capabilities so they can support other users as the application is deployed and operational procedures can be streamlined based on the new application. And yes, there is the vital task of ensuring that the new application does meet the current needs of the business.
Moving to UAT 2.0 needs more than a PR rebrand; it needs new commitments and approaches so the massive benefits are not lost in the painful mechanics. How do we start?
UAT 2.0 demands a maximum of two UAT cycles
. Any more than that, and users will become demotivated, but that’s not the point. Any more than two cycles show that the application simply wasn’t ready for the UAT stage. Such applications are a waste of the user’s time and a distraction to the business.
Automated regression testing has a part to play.
If you select a tool that can deliver test assets in hours rather than weeks, then as each area of the new application has been successfully reviewed, automation can be used to ensure that any collateral damage from any subsequent changes can be identified without asking the users to cover the ground again.
Forget spreadsheets and screenshots
UAT 2.0 doesn’t rely on spreadsheets to track progress or emails with the occasional screenshot to report problems. Great tools exist to plan and manage the process, and users can be empowered with tools that will track every test so that every problem is fully documented. By taking this approach, users will be better motivated, the UAT cycle will be shortened, and the time to fix issues will be shorter.
UAT is the last test before an application is deployed. It is the final quality gate. Investing in UAT 2.0 will have a rapid payback and make a positive impact on everyone involved.
Ready to learn more?
It’ll come as no surprise that we offer a UAT solution to organizations that know they could be doing UAT better but lack the tools in-house to make it happen. Our solution works with all major ERP systems, including Infor, SAP, and IBMi, and will even work with custom-built systems. Essentially, if it’s a part of running your business, we can help you test it.
If you’d like to learn more about how we can help you fix your UAT, just click below.
