Testing the future

When thinking about the next challenges and opportunities for delivering quality software, here are 3 areas that I think provoke thought.

  1. Roles

  2. Tools

  3. Achieving Parity

Testing Roles

The last 10 or so years have seen the evolution of the QA role from the person at the end of the line that runs tests, to an integrated member of a delivery team. There has also been a shift to automation, often with an expectation that testers come with coding skills. I have always been somewhat sceptical of the automation role in the QA space because they are not particularly complementary skill sets. Where is the skill link in the ability to craft a great automation suite and the Tester’s mindset that makes an application useable and breaks down the use cases in order to validate them? Clearly, some people have these overlapping skill sets, but nothing in one inherently leads to the other. As we’ll cover later in the sections, when tools improve and the machines take over the driving of tests and their execution, what’s going to be left is validating the actual user experience.

Venn Diagram

I advise QA’s working in agile teams they should keep a hybrid mindset, sitting in the middle of this Venn diagram

A model to progress towards might look more like all the team having responsibilities for baking in quality as part of their respective roles. Possibly with a dedicated role assuming more of a coach-type capacity, across teams where needed.

Future role considerations

The team members in this model each have an inherent responsibility to quality, aligned with the skills they have. Developers might be constructing the frameworks for testing the application for example. The “what” of what is being tested should remain independent of the person writing the code to maintain a separate perspective, but the core skills stay within roles. A similar example would be a Product Owner viewing the software through the user’s lens, as might have been historically covered in UAT cycles.

Testing Tools

AI is certainly the buzzword of the moment and it’s surely going to have a big impact on the future of testing. Asking an AI how to test your application may well be the first step in a test plan of the future. Likely the output will be a pretty strong approach, given the binary nature of test cases and how a smart AI can distil that information methodically. The integration of AI in this context should be met with the same response as any other place AI is encountered, the human’s job is to maintain the human experience. And lose the repetitive, boring and methodical. For those with software quality in mind, this means maintaining the experience and usability of the software, for actual humans.

Another area that tooling will considerably alter testing in the future, is the inevitable improvements in testing frameworks. Improvement in the capabilities of tooling may minimise the need for bespoke automation engineering. Much like the evolution of site builders to output websites, which in their early days were rudimentary and needed expertise to customise. Current products are much more flexible, without technical expertise, allowing users to build unique sites.

An example of where I see something like this progressing is the integration of web driver capability directly into the application source code. How many times have we seen automation suites fail because a code commit has changed the interface presentation and the web driver can no longer execute the test? If a tool can abstract the label function and orchestrate the test, even as the code changes, then the painful maintenance of the test code is removed.

Achieving Parity

In the last year, I have spent a lot of time in different parts of the country and have needed to change and interact with various public services quite regularly. Be that enlisting temporarily at a doctor's or paying a council tax bill, it’s been a real reminder of how far behind the services in the public sector are compared to those in the private sector.

From a general quality perspective, there is a need to ensure the services that are paid for by the public purse are delivering a great experience to their users. Not least because poor, disjointed and broken processes have costs and implications for those who use and pay for them.

Previous
Previous

The start, stop, continue of retrospectives