There is a lot of focus on shifting testing earlier in the lifecycle. I totally get it, embrace it and encourage it. In my view, I don’t actually think people are necessarily thinking far enough left, but that is my opinion and a future piece for sure.
However, as we look along the “when testing should be adopted” timeline, there is still an area we often see neglected across all sectors, domains, methods and technologies – further right, in acceptance testing. Despite being in 2020, the business sponsors and users are often still considered the “them”, as the “us” (IT teams) try to outwit them with great sounding products, great technical descriptions and very often partly working systems!
These key people are usually swamped with a day job, and in between making the company money, saving costs or generally doing good, they have to fit in the testing of a solution that can often be a surprise and often not what they expected / wanted / needed (* delete as most common). But. And it’s a big but, they are vital to the system going live.
I have commented many times on the lack of business engagement in projects, but for the remainder of this post, I am going to assume we have full buy-in. I am going big. I will suggest they are keen to use the new system, excited about the project, and whoop, whoop, they are chuffed they have been assigned to do the acceptance testing.
So, everyone, you back on your seats?
Well, lets empower them. As a father, my kids often say, don’t treat me like a child. I am 15/13. Ok, so let’s do the same with the business users. We should treat them like competent professionals, armed with tools and technologies that support them automating the acceptance testing.
What we need is those key people ensuring that we have a solution that meets the needs of the business, is easy to use in the environment it is intended, does not expose the organisation to inherent risk and most importantly, gets them excited and wanting to use it.
By introducing test automation to them, taking them on a journey, we can remove the dark art of technology and speed them up in delivering their expertise and experience so that they can continue to do their day jobs. We did this recently for a client and saved them 600 business days a year. Even at minimum wage, that is a lot. But trust me, this was across a function with likely six figure salaries involved.
The role of the test team will be to create robust test automation frameworks, adopt and coach in BDD, ensure non-technical teams can build automation scripts, support, through API’s, the injection of data to focus the users time on results and interpretation, and not input. We are now also working on Dynamics programmes where the automation of user acceptance is being baked in, using the RSAT solution. We need to push this evolution further.
We should give the business confidence to explore greater coverage in higher risk areas with little extra effort – pacifying legacy fears of system gotcha’s.
We can free up time so that Jim or Jane, who have worked in the business for 15 years, can spend time exploring where the gremlins are usually found in the system – the high business risk areas and where deep knowledge is absolutely vital.
As technology companies and professionals, we talk about Agile and DevOps, in great depth, and the bedding in of the “business” into our scrum teams and our squads, but it is still, at this moment in time, a minority of projects that are run this way.
We need to harness the technical knowledge and empower more people with test automation. I strongly recommend that a quick and easy win will be the acceptance phase. It will mean engaging the business earlier, it will mean upskilling a key business team and it will develop the soft skills of the wider technology community. All this sounds good to me.
As always, happy to be challenged and open a conversation.
Stephen Johnson – Co-founder & Director, ROQ